Re: OS stopping stack buffer overflow exploits

Date: Sun Jun 04 2000 - 14:23:56 EST

As pointed out by other people Solar Designer has already done this.[1]

The fact is that this doesn't offer much more than a speedbump. It
doesn't prevent you from jumping around to arbitrary locations in memory,
and there will almost always be something useful to you in libc or in the
PLT. If system() is in the PLT then you've got a straight-forwards
exploit. Otherwise look for something like strcpy() and copy your
shellcode into the GOT or another rwx page and then jump there. You don't
need an executable stack.

Libsafe[2] or Stackguard[3] provide better (although still not
perfect) protection. I recommend reading the Libsafe white paper since it
touches on the non-exec-stack issues and references a linux-kernel post
from linus w.r.t why such a patch will not be accepted in the kernel.


On Sat, 3 Jun 2000, Robert Redelmeier wrote:
> While thinking about stack buffer overflow exploits (like `bind`),
> it occured to me that our beloved OS [Linux] might be able to
> provide some security for the many poorly-written suid-root apps.
> The key to these exploits is the ability to hijack the thread
> of execution by overwriting the return address on the stack.
> There are a couple of x86 mechanisms that could be used to
> stop the hijack:
> 1) The limit portion of the processes' CS segment descriptor
> could be adjusted downwards, so the stack addresses would not
> be executable and attempting would trigger a #GP exception.
> 2) On syscall entry, the kernel could check the page tables
> to be sure that the return address is from code pages (read-only),
> and not from data pages (read-write). The kernel would log and
> terminate any such process. Kill some nasty bugs this way too.
> This assumes an exploit can do limited damage without syscalls.
> I believe that even root processes really are running at
> Intel Ring3 privilige level. This greatly limits what bare
> code can do. AFAIK, only the kernel runs in Ring0.
> Of course, either or both of these might break some poorly
> behaved applications.
> -- Robert
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at

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

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:19 EST