>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.
>
>It probably takes all of five lines of changes to some existing exploit,
>and some random program to find out where in the address space the shared
>libraries tend to be loaded.
from the Secure-Linux patch docs:
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.
Another way to exploit a buffer overflow is to point the return address to
a function in libc, usually system(). This patch also changes the default
address that shared libraries are mmap()ed at to make it always contain a
zero byte. This makes it impossible to specify any more data (parameters
to the function, or more copies of the return address when filling with a
pattern) in an exploit that has to do with ASCIIZ strings (this is the case
for most buffer overflow vulnerabilities).
-
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.altern.org/andrebalsa/doc/lkml-faq.html