lkml.org 
[lkml]   [1999]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Unexecutable Stack / Buffer Overflow Exploits...
Date
From
Gregory Maxwell <greg@linuxpower.cx> said:
> On Wed, 29 Dec 1999, Horst von Brand wrote:
> [snip]
> > Where do you think script kiddies get their exploit scripts from? They
> > don't write them themselves: The real crackers share them with the
> > community. Just like the hacker community shares patches and cool
> > programs. So you can keep out 99.99% only until one of the 0.01% finds out
> > a way around it. The danger of "nonexecutable stack" is that it creates a
> > sense of security, which might be justified as long as it is rare. Once it
> > becomes widespread, it will be useless in short time, and _everybody_ will
> > have to pay the cost for nothing at all, while feeling smugly secure.

> Here is where the real argument lives.

> You are claiming that the patch adds no real security. You clame it does
> nothing more then moving to a non-popular arch would do.

> I disagree. The patch actually makes creating this type of attack much
> harder, and in some cases impossible.

"Much harder" how? Instead of returning to some doctored code on the stack,
you just return to the start of system(3) or some such. Sure, different
technique, perhaps needs to be tuned and adjusted according to the target
program and its version and a few more parameters. Impossible? Well,
perhaps against statically linked programs that don't contain such stuff,
but as long as you have a shared libc you are vulnerable AFAIKS. And you
could fake a trampoline on the stack too...

And note that the latest round of attacks against Solaris bind (I never run
stock distribution servers as a policy matter, they usually lag _way_
behind in security) gave me a _huge_ /var/adm/messages, full of messages
from bind that was being bombarded with many thousands of weird requests.
Installing nonexecutable stack would have given me a whole bunch of nice
core files, and a nameserver that did not work for more than a couple of
seconds at a time. That isn't exactly "security" in my book.

> The effectiveness of this patch comes from two places:

> A) It's rare and breaks all existing attacks.
> B) I actually makes that class of attack harder to accomplish.

> Just because A will go away if this patch were everywhere, you still
> derrive additional security from B.

A bit of extra security, at the cost of adding cruft to the kernel each
time a new trampoline code layout comes around, some performance hit for
everybody and DoSes all over the place instead of getting the broken
programs fixed? No, thanks.

If you want to install it, go right ahead: this is free software in a free
world. It might help you some for some time, but does _not_ help everybody,
at least not in the long run.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2011 Jasper Spaans