Skip to Content.
Sympa Menu

ndt-users - Re: Web100srv buffer overflow

Subject: ndt-users list created

List archive

Re: Web100srv buffer overflow


Chronological Thread 
  • From: Tom Throckmorton <>
  • To: Aris Adamantiadis <>
  • Cc: Clint Simmons <>,
  • Subject: Re: Web100srv buffer overflow
  • Date: Sat, 8 May 2010 08:57:53 -0400

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"



Archive powered by MHonArc 2.6.16.

Top of Page