ndt-users list created

["Clint Simmons" <>]

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"
>
>