[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Unexecutable Stack / Buffer Overflow Exploits...
In <> Dan Hollis ( wrote:
> On Wed, 29 Dec 1999, Horst von Brand wrote:
>> 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.

> Thats why it should be a kernel *option*. Then everyone can enable it
> except you.

No. It SHOULD not be kernel option. Linus already said final verdict on
subject: no way for standard kernel. If you are scilled enough to apply
patch you at least not newbee, who thinks "hey, it's some security tool...
I my enable it just in case". And Linus personally thinks that subj will
not improve security much (he showed idea how to convert "normal" exploit
in "unxecutable stack" exploit if I recall correcly). It's general technique:
(when standard glibc is used: you DO NOT NEED TO EXECUTE anything except
ONE syscall to make /bin/sh suid -- you just push arguments for
libc's internal function __chmod in buffer, push return address for
__chmod there (with right offset, of course) and viala: you have suid /bin/sh
to start with (server will crash afterwards but it's other story). Is it REALLY
that harder then playing tricks with executable stack ? Or all you vulnerable
daemons are not using shared libc ??? Get real.

P.S. It's just simple sample. Of course this generalisation does not work for
remote attacks -- you should be little more clever. LOTS OF attacks can be
similarly generalised: just find appropriate routine in glibc -- there are
enough interesting funstions. Just VERY few will be unexploitable with
unxecutable stack at all. And they WILL be if unxecutable stack option will
be popular enough. And such versions will be available for downloads in "usual
places". Now we are in square one.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.068 / U:7.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site