Messages in this thread | | | From | "Khimenko Victor" <> | Date | Thu, 30 Dec 1999 13:19:15 +0300 (MSK) | Subject | Re: Unexecutable Stack / Buffer Overflow Exploits... |
| |
In <Pine.LNX.4.10.9912291834180.2558-100000@anime.net> Dan Hollis (goemon@sasami.anime.net) 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |