ndt-users list created

[Matt Mathis <>]

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