Follow up to NSE issues and gh_list assert() failure (Was 4.85BETA2 posted...)

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Previously I reported strange behavior with NSE as well as an assertion
failure with gh_list in:

http://seclists.org/nmap-dev/2009/q1/0311.html (NSE causing gh_list error)
http://seclists.org/nmap-dev/2009/q1/0230.html (NSE eating memory)
http://seclists.org/nmap-dev/2009/q1/0258.html (NSE eating CPU)
http://seclists.org/nmap-dev/2009/q1/0505.html (NSE backtrace of hang)
http://seclists.org/nmap-dev/2009/q1/0519.html (NSE deadlock)

David has been most generous with his time and helped me try track down
and troubleshoot these problem.  It seems all of these problems are
probably related to a memory corruption problem in NSE.

With some work in Valgrind to cut down OpenSSL warnings[1], I've gotten
NSE to die with:

nmap: gh_list.c:348: gh_list_remove_elem: Assertion `list->count != 0 || (list->first == ((void *)0) && list->last == 
((void *)0))' failed.

This error is slightly different than the previous gh_list error I
reported.  I have included a backtrace[2] at the end of this email as to
not clutter things more than they already are.

I have produced two Valgrind outputs, the first using the
Gentoo-provided Lua here:

http://noh.ucsd.edu/~bmenrigh/val_log.txt

And the second using the included Lua (for line numbers and symbol
names):

http://noh.ucsd.edu/~bmenrigh/val_log2.txt

The first log appears to be the more interesting of the two.  David has
pointed out that the entries like this one indicate that NSE is reading
and using memory that was already freed by the Lua garbage collector:

==12614== 
==12614== Invalid read of size 8
==12614==    at 0x58427C3: lua_pushboolean (in /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x46B523: l_nsock_checkstatus(lua_State*, void*) (nse_nsock.cc:412)
==12614==    by 0x46F02D: l_nsock_receive_handler(void*, void*, void*) (nse_nsock.cc:605)
==12614==    by 0x47BBA9: msevent_dispatch_and_delete (nsock_event.c:297)
==12614==    by 0x47A0BC: nsock_loop (nsock_core.c:913)
==12614==    by 0x468FBB: process_mainloop(lua_State*) (nse_main.cc:465)
==12614==    by 0x469DE7: script_scan(std::vector<Target*, std::allocator<Target*> >&) (nse_main.cc:368)
==12614==    by 0x41DA73: nmap_main(int, char**) (nmap.cc:1822)
==12614==    by 0x4197D6: main (main.cc:224)
==12614==  Address 0xa5ab3c8 is 16 bytes inside a block of size 184 free'd
==12614==    at 0x4C20A6A: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==12614==    by 0x5850634: (within /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x584973B: (within /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x5847ECB: (within /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x58480F2: (within /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x58484C2: (within /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x5842CA7: lua_gc (in /usr/lib64/liblua.so.5.1.3)
==12614==    by 0x4691C5: process_mainloop(lua_State*) (nse_main.cc:500)
==12614==    by 0x469DE7: script_scan(std::vector<Target*, std::allocator<Target*> >&) (nse_main.cc:368)
==12614==    by 0x41DA73: nmap_main(int, char**) (nmap.cc:1822)
==12614==    by 0x4197D6: main (main.cc:224)

He and I also think that the errors like

==12614== Use of uninitialised value of size 8

Where OpenSSL was involved, eg: l_rand_pseudo_bytes(lua_State*)
(nse_openssl.cc:201) are not a problem and stem from the way OpenSSL
gathers entropy.


What all of this probably boils down to is that NSE is holding onto and
even making use of important values that are getting reaped by
lua_gc().  The bug may be subtle or it may be blatant.

I suppose it would be worthwhile to try to determine which commit(s)
started the error(s) showing up.  Because of the random nature of the
problem (memory, CPU, deadlock, assertion) this could be very difficult
to do with any certainty.

Hopefully we'll be able figure this one out in a reasonable amount of
time.


Brandon


[1] If you are going to run Nmap in Valgrind you'll want to exclude all
the warnings OpenSSL generates by using this file:

http://noh.ucsd.edu/~bmenrigh/nmap_val.supp


[2] A backtrace of the gh_list assertion error:

#0  0x00007fbebe4823c5 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007fbebe4823c5 in raise () from /lib/libc.so.6
#1  0x00007fbebe48373e in abort () from /lib/libc.so.6
#2  0x00007fbebe47bb1f in __assert_fail () from /lib/libc.so.6
#3  0x000000000047cf8c in gh_list_remove_elem (list=<value optimized out>,
    elem=<value optimized out>) at gh_list.c:348
#4  0x000000000047a0cd in nsock_loop (nsp=0xcec0e0, msec_timeout=50)
    at nsock_core.c:915
#5  0x0000000000468fbc in process_mainloop (L=0xc99da0) at nse_main.cc:465
#6  0x0000000000469de8 in script_scan (targets=@0x305c240) at nse_main.cc:368
#7  0x000000000041da74 in nmap_main (argc=17, argv=0x7fffc7f77658)
    at nmap.cc:1822
#8  0x00000000004197d7 in main (argc=17, argv=0x7fffc7f77658) at main.cc:224


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkml8E0ACgkQqaGPzAsl94J0qwCeKVJ5IFwLMKuhwnYX4jB7qjLz
8VMAn2ldvBF0eY65BJ751dltMspANfsD
=m6sq
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org