ndt-users list created

[Aris Adamantiadis <>]

Hi Clint,

Could you run it through gdb ?
gdb -q /usr/local/sbin/web100src
run -dddddd -r -a -i eth1
(wait for the crash)
bt

(the last command prints a backtrace, like the one provided by the
libc, but with debugging informations like line numbers.

kr,

Aris

Clint Simmons a écrit :
> Just for testing.. I went ahead and recompiled both web100userland and ndt 
> with the suggested flags
> 
> Using - gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
> 
> " CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
> -fasynchronous-unwind-tables' ./configure"
> 
> Without any luck I got the same results. The buffer overflow happens 
> immediately after every attempt to start the process. (same as before)
> 
> root@nms:/usr/local/src/web100_userland-1.7#
>  /usr/local/sbin/web100srv -ddddddd -r -a -i eth1
>  Reading config file /etc/ndt.conf to obtain options
> ANL/Internet2 NDT ver 3.6.2b
>         Variables file = /usr/local/ndt/web100_variables
>         log file = /usr/local/ndt/web100srv.log
>         Admin file = /usr/local/ndt/admin.html
>         Debug level set to 7
> 
> Send buffer initialized to 65535, Receive buffer initialized to 87380
> server ready on port 1494
> web100_init() read 69 variables from file
> *** buffer overflow detected ***: /usr/local/sbin/web100srv terminated
> ======= Backtrace: =========
> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7695ed8]
> /lib/tls/i686/cmov/libc.so.6[0xb7694f10]
> /lib/tls/i686/cmov/libc.so.6(__fgets_chk+0x129)[0xb7695239]
> /usr/local/sbin/web100srv[0x8059732]
> /usr/local/sbin/web100srv[0x805067c]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb75cbb56]
> /usr/local/sbin/web100srv[0x804aca1]
> ======= Memory map: ========
> 08048000-0806f000 r-xp 00000000 48:01 3881       /usr/local/sbin/web100srv
> 0806f000-08070000 r--p 00026000 48:01 3881       /usr/local/sbin/web100srv
> 08070000-08071000 rw-p 00027000 48:01 3881       /usr/local/sbin/web100srv
> 08071000-08085000 rw-p 00000000 00:00 0
> 08cbd000-08cde000 rw-p 00000000 00:00 0          [heap]
> b755e000-b757a000 r-xp 00000000 48:01 635        /lib/libgcc_s.so.1
> b757a000-b757b000 r--p 0001b000 48:01 635        /lib/libgcc_s.so.1
> b757b000-b757c000 rw-p 0001c000 48:01 635        /lib/libgcc_s.so.1
> b7584000-b7586000 r-xp 00000000 48:01 4112       /lib/libnss_mdns4.so.2
> b7586000-b7587000 r--p 00001000 48:01 4112       /lib/libnss_mdns4.so.2
> b7587000-b7588000 rw-p 00002000 48:01 4112       /lib/libnss_mdns4.so.2
> b7588000-b7598000 r-xp 00000000 48:01 629        
> /lib/tls/i686/cmov/libresolv-2.10.1.so
> b7598000-b7599000 r--p 00010000 48:01 629        
> /lib/tls/i686/cmov/libresolv-2.10.1.so
> b7599000-b759a000 rw-p 00011000 48:01 629        
> /lib/tls/i686/cmov/libresolv-2.10.1.so
> b759a000-b759c000 rw-p 00000000 00:00 0
> b759c000-b75a1000 r-xp 00000000 48:01 326        
> /lib/tls/i686/cmov/libnss_dns-2.10.1.so
> b75a1000-b75a2000 r--p 00004000 48:01 326        
> /lib/tls/i686/cmov/libnss_dns-2.10.1.so
> b75a2000-b75a3000 rw-p 00005000 48:01 326        
> /lib/tls/i686/cmov/libnss_dns-2.10.1.so
> b75a3000-b75a5000 r-xp 00000000 48:01 4113       
> /lib/libnss_mdns4_minimal.so.2
> b75a5000-b75a6000 r--p 00001000 48:01 4113       
> /lib/libnss_mdns4_minimal.so.2
> b75a6000-b75a7000 rw-p 00002000 48:01 4113       
> /lib/libnss_mdns4_minimal.so.2
> b75a7000-b75b1000 r-xp 00000000 48:01 599        
> /lib/tls/i686/cmov/libnss_files-2.10.1.so
> b75b1000-b75b2000 r--p 00009000 48:01 599        
> /lib/tls/i686/cmov/libnss_files-2.10.1.so
> b75b2000-b75b3000 rw-p 0000a000 48:01 599        
> /lib/tls/i686/cmov/libnss_files-2.10.1.so
> b75b3000-b75b5000 rw-p 00000000 00:00 0
> b75b5000-b76f3000 r-xp 00000000 48:01 232        
> /lib/tls/i686/cmov/libc-2.10.1.so
> b76f3000-b76f4000 ---p 0013e000 48:01 232        
> /lib/tls/i686/cmov/libc-2.10.1.so
> b76f4000-b76f6000 r--p 0013e000 48:01 232        
> /lib/tls/i686/cmov/libc-2.10.1.so
> b76f6000-b76f7000 rw-p 00140000 48:01 232        
> /lib/tls/i686/cmov/libc-2.10.1.so
> b76f7000-b76fa000 rw-p 00000000 00:00 0
> b76fa000-b770e000 r-xp 00000000 48:01 591        /lib/libz.so.1.2.3.3
> b770e000-b770f000 r--p 00013000 48:01 591        /lib/libz.so.1.2.3.3
> b770f000-b7710000 rw-p 00014000 48:01 591        /lib/libz.so.1.2.3.3
> b7710000-b7725000 r-xp 00000000 48:01 628        
> /lib/tls/i686/cmov/libpthread-2.10.1.so
> b7725000-b7726000 r--p 00014000 48:01 628        
> /lib/tls/i686/cmov/libpthread-2.10.1.so
> b7726000-b7727000 rw-p 00015000 48:01 628        
> /lib/tls/i686/cmov/libpthread-2.10.1.so
> b7727000-b7729000 rw-p 00000000 00:00 0
> b7729000-b774d000 r-xp 00000000 48:01 287        
> /lib/tls/i686/cmov/libm-2.10.1.so
> b774d000-b774e000 r--p 00023000 48:01 287        
> /lib/tls/i686/cmov/libm-2.10.1.so
> b774e000-b774f000 rw-p 00024000 48:01 287        
> /lib/tls/i686/cmov/libm-2.10.1.so
> b774f000-b7780000 r-xp 00000000 48:01 143756     /usr/lib/libpcap.so.1.0.0
> b7780000-b7781000 r--p 00031000 48:01 143756     /usr/lib/libpcap.so.1.0.0
> b7781000-b7782000 rw-p 00032000 48:01 143756     /usr/lib/libpcap.so.1.0.0
> b7789000-b778a000 rw-p 00000000 00:00 0
> b778a000-b778f000 r-xp 00000000 48:01 3953       
> /usr/local/lib/libweb100.so.0.3.2
> b778f000-b7790000 r--p 00004000 48:01 3953       
> /usr/local/lib/libweb100.so.0.3.2
> b7790000-b7791000 rw-p 00005000 48:01 3953       
> /usr/local/lib/libweb100.so.0.3.2
> b7791000-b7793000 rw-p 00000000 00:00 0
> b7793000-b7794000 r-xp 00000000 00:00 0          [vdso]
> b7794000-b77af000 r-xp 00000000 48:01 176        /lib/ld-2.10.1.so
> b77af000-b77b0000 r--p 0001a000 48:01 176        /lib/ld-2.10.1.so
> b77b0000-b77b1000 rw-p 0001b000 48:01 176        /lib/ld-2.10.1.so
> bfb1d000-bfb32000 rw-p 00000000 00:00 0          [stack]
> Signal 6 received by process 1129
> Aborted
> 
> 
> 
> 
> 
> 
> Thanks,
> Clint
> 
> 
> 
> -----Original Message-----
> From: Matt Mathis 
> [mailto:]
>  
> Sent: 8. May 2010 8:59
> To: Tom Throckmorton
> Cc: Aris Adamantiadis; Clint Simmons; 
> 
> Subject: Re: Web100srv buffer overflow
> 
> I think you will find that the web100 library does some things that
> strict bounds checking will never pass: pointer casts to arrays of
> unknown sizes.  This is because the web100 library walks the header
> file  (/proc/web100/header) at runtime to pick values out of the
> binary structure returned by the kernel.
> 
> It is possible that more paranoia might be appropriate, but exploits
> probably either require the kernel returns a header that doesn't match
> the kernels own binary data, or an application that corrupts the
> (nominally constant) list representation of the header file.
> 
> That said, at the very minimum, it would be good to insert some
> appropriate pragma's to head off the compilation problems for others.
> 
> Patches would be a good thing.
> 
> Thanks,
> --MM--
> -------------------------------------------
> Matt Mathis    Home/Cell:412.654.7529
> I am now at Google
> -------------------------------------------
> Evil is defined by mortals who think they know
> "The Truth" and use force to apply it to others.
> 
> 
> 
> On Sat, May 8, 2010 at 8:57 AM, Tom Throckmorton 
> <>
>  wrote:
>> On May 08 12:12, Aris Adamantiadis wrote:
>>> Tom Throckmorton a écrit :
>>>
>>>>> You could try re-compiling w/ more permissive flags - I will try this 
>>>>> version
>>>>> myself and see how it builds/runs.
>>> Sorry, That's the worst security advice I have ever heard about how to
>>> resolve a buffer overflow problem. Disabling a security feature can in
>>> fact make the problem worse.
>> Agreed - taken out of context it is bad advice, but note though that I 
>> wasn't
>> giving security advice per se, but rather troubleshooting a build, and my
>> suggestion of attempting a rebuild w/ more permissive flags would help
>> determine if that was indeed the issue in this (beta) release.
>>
>>> The procedure is the following:
>>> 1-understand what's happening and how the buffer overflow happened.
>>> This includes finding a reliable way to reproduce it into valgrind.
>>> 2-Find the problematic code and understand why there was a buffer
>>> overflow. Maybe it's a compilation issue (A and B compiled with
>>> different values for x) or a coding error.
>>> 3-Understand the scope of the problem (local DoS, remote DoS, remote
>>> arbitrary code execution !)
>>> 4-Patch it, release an advisory if it's serious, along with ways to
>>> mitigate the problem if you can't upgrade (fstack-protector is a good
>>> mitigation technique, hence why disabling it is a bad idea).
>>> 5-hope everybody will upgrade.
>>>
>>> While I understand it's not everyone's responsibility to do 1-5, I
>>> think we can help to 1-3.
>> I think between us all we can do 1-5, actually.
>>
>> Do you consider yourself adept at 1-3?  Can you build these versions of 
>> code
>> and _not_ see this issue?
>>
>>> Then, My question would be : are you able to reproduce the problem at
>>> each time ? could you compile web100srv with debugging support
>>> (CFLAGS=-g) without altering anything, and then reproduce the problem
>>> again ? Getting a stacktrace is an excellent way of understanding what
>>> happened.
>> Agreed, on reproducibility being a great way to narrow the issue - that's 
>> where
>> I was heading.
>>
>>> Thanks and sorry if I was a little rude.
>> I read that as passion, not rudeness.
>>
>> Cheers,
>>
>> -tt
>>
>> --
>> Tom Throckmorton
>> MCNC - Advanced Services Development
>> 3021 Cornwallis Road
>> Research Triangle Park, NC 27709
>> 919.248.1448
>>
>> "Connecting North Carolina's future today"
>>
>>
>