ndt-users - Re: Web100srv buffer overflow
Subject: ndt-users list created
List archive
- 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"
- Web100srv buffer overflow, Clint Simmons, 05/07/2010
- Re: Web100srv buffer overflow, Tom Throckmorton, 05/07/2010
- Re: Web100srv buffer overflow, Tom Throckmorton, 05/07/2010
- Re: Web100srv buffer overflow, Aris Adamantiadis, 05/08/2010
- Re: Web100srv buffer overflow, Tom Throckmorton, 05/08/2010
- Re: Web100srv buffer overflow, Matt Mathis, 05/08/2010
- RE: Web100srv buffer overflow, Clint Simmons, 05/10/2010
- Re: Web100srv buffer overflow, Aris Adamantiadis, 05/10/2010
- Re: Web100srv buffer overflow, Jason Zurawski, 05/10/2010
- Re: Web100srv buffer overflow, Rich Carlson, 05/11/2010
- RE: Web100srv buffer overflow, Clint Simmons, 05/11/2010
- RE: Web100srv buffer overflow, Clint Simmons, 05/10/2010
- Re: Web100srv buffer overflow, Matt Mathis, 05/08/2010
- Re: Web100srv buffer overflow, Tom Throckmorton, 05/08/2010
- Re: Web100srv buffer overflow, Aris Adamantiadis, 05/08/2010
- Re: Web100srv buffer overflow, Tom Throckmorton, 05/07/2010
- Re: Web100srv buffer overflow, Tom Throckmorton, 05/07/2010
Archive powered by MHonArc 2.6.16.