ndt-users list created

["Clint Simmons" <>]

Rich..

That did the trick!

Yesterday I blew away the box and reinstalled everything fresh; so knowing 
now it wasn't some screwed up libraries.. :)

I guess I should downgrade for now until you have a fix..

Thanks!

-----Original Message-----
From: Rich Carlson 
[mailto:]
 
Sent: 11. may 2010 8:00
To: Clint Simmons
Cc: Matt Mathis; Tom Throckmorton; Aris Adamantiadis; 

Subject: Re: Web100srv buffer overflow

Aris;

Arrg, sorry I didn't notice this before.

Remove/rename the NDT log file /usr/local/ndt/web100srv.log and try 
again.  The server reads this file at startup to set the variables for 
the admin screen (enabled by the -a flag).  There is a bug in the parser 
that can cause the server process to crash.  I don't have a fix yet, but 
I know this problem exists.  Removing the log file, is the quickest way 
to get going again.

Also, the server now dynamically scans the interface list using the 
local IP address to find the incoming interface.  You should no longer 
need to use the -i ethx flag.

Rich

On 5/10/2010 5:14 PM, Clint Simmons wrote:
>
> 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"
>>
>>
>