Re: announcing PaX

[Dylan Griffiths <Dylan_G () BIGFOOT COM>]

PaX wrote:
> the PaX team is pleased to announce that an implementation
> of the PAGE_EXEC flag has been made available at

> From the PaX website:
"   this document discusses the possibility of implementing non-executable
   pages for IA-32 processors (i.e. pages which user mode code can read or
   write, but cannot execute code in). since the processor's native page
   table/directory entry format has no provision for such a feature, it is
   a non-trivial task."

> From a posting to Linux-Kernel on August, 1998 (
http://lwn.net/980806/a/linus-noexec.html ):
"It's _really_ easy. You do something like this:
 - overflow the buffer on the stack, so that the return value is
   overwritten by a pointer to the "system()" library function.
 - the next four bytes are crap (a "return pointer" for the system call,
   which you don't care about)
 - the next four bytes are a pointer to some random place in the shared
   library again that contains the string "/bin/sh" (and yes, just do a
   strings on the thing and you'll find it).

Voila. You didn't have to write any code, the _only_ thing you needed to
know was where the library is loaded by default. And yes, it's
library-specific, but hey, you just select one specific commonly used
version to crash.

Suddenly you have a root shell on the system.

So it's not only doable, it's fairly trivial to do.

In short, anybody who thinks that the non-executable stack gives them any
real security is very very much living in a dream world. It may catch a
few attacks for old binaries that have security problems, but the basic
problem is that the binaries allow you to overwrite their stacks. And if
they allow that, then they allow the above exploit. "

And, let's not forget, this has been done before in Solar Designer's patch
for Linux ( http://www.openwall.com/linux/ )
" Non-executable user stack area
--------------------------------
Most buffer overflow exploits are based on overwriting a function's return
address on the stack to point to some arbitrary code, which is also put
onto the stack.  If the stack area is non-executable, buffer overflow
vulnerabilities become harder to exploit."

--
    www.kuro5hin.org -- technology and culture, from the trenches.