Nmap Development mailing list archives

Adler32 addition to Nbase in r12676 causing rare segfault


From: Brandon Enright <bmenrigh () ucsd edu>
Date: Wed, 15 Apr 2009 20:16:23 +0000

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

I just ran into a segfault in the new Adler32 code in Nbase.  I'm
seriously pressed for time at the moment so I won't be able to help
troubleshoot for a day or two.

Here is what I have:

Program terminated with signal 11, Segmentation fault.
[New process 15092]
#0  adler32 (buf=<value optimized out>, len=123137424) at nbase_misc.c:460
460         s1 = (s1 + buf[n]) % ADLER32_BASE;
(gdb) bt
#0  adler32 (buf=<value optimized out>, len=123137424) at nbase_misc.c:460
#1  0x00007f2309cb0ee8 in inflate () from /lib/libz.so.1
#2  0x00007f230aebb4d8 in ?? () from /usr/lib/libcrypto.so.0.9.8
#3  0x00007f230aeba8f1 in COMP_expand_block () from /usr/lib/libcrypto.so.0.9.8
#4  0x00007f230b157f3d in ssl3_do_uncompress () from /usr/lib/libssl.so.0.9.8
#5  0x00007f230b158470 in ssl3_read_bytes () from /usr/lib/libssl.so.0.9.8
#6  0x00007f230b15921d in ssl3_get_message () from /usr/lib/libssl.so.0.9.8
#7  0x00007f230b1597f2 in ssl3_get_finished () from /usr/lib/libssl.so.0.9.8
#8  0x00007f230b154cdf in ssl3_connect () from /usr/lib/libssl.so.0.9.8
#9  0x00000000004755f0 in handle_connect_result (ms=0x750bc60, nse=0x750f170, 
    status=16) at nsock_core.c:348
#10 0x0000000000476b5d in nsock_loop (nsp=0x750bc60, msec_timeout=-1)
    at nsock_core.c:828
#11 0x000000000045d788 in service_scan (Targets=@0x7fff139e6b10)
    at service_scan.cc:2435
#12 0x000000000041db2d in nmap_main (argc=35, argv=0x7fff139e9db8)
    at nmap.cc:1787
#13 0x0000000000418f37 in main (argc=35, argv=0x7fff139e9db8) at main.cc:215
Current language:  auto; currently c


I've gotten quite a handful of these crashes (~20), here is an
interesting print from another core dump:

Program terminated with signal 11, Segmentation fault.
[New process 24252]
#0  0x00000000004767e8 in adler32 (buf=0x1 <Address 0x1 out of bounds>, 
    len=110187248) at nbase_misc.c:460
460         s1 = (s1 + buf[n]) % ADLER32_BASE;


If I had to guess, I'd say that the length field is insanely big,
causing a overflow somewhere and overwriting the buf pointer.  Since I
haven't looked at any code yet this is 110% guessing.

If the problem isn't obvious, I'll suggest adding a few assert()s here
and there.  I'll try to reproduce the problem in Valgrind in a few days
if it isn't fixed by then.

Brandon

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

iEYEARECAAYFAknmQJ0ACgkQqaGPzAsl94LaQQCdFRGO/F16eMLKjDqQr4/vaGyM
UH4An10cvBpeWaGHBnvzbf43Gdxoe+5s
=sKNK
-----END PGP SIGNATURE-----

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


Current thread: