Re: OS stopping stack buffer overflow exploits

From: James Sutherland (
Date: Sun Jun 04 2000 - 02:28:14 EST

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.

This is just a non-executable stack; fairly common already, IIRC, at least
in some systems.

> 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.

Non-executable code. The process can certainly do this for itself via
mmap(); I'm not sure what the default permissions from malloc() are.

> 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.

Correct: all user processes are R3, kernel = R0 on x86. (Also known as
"user mode" and "kernel mode", which makes this seem rather more obvious.)

> Of course, either or both of these might break some poorly
> behaved applications.

That's part of the problem. These two checks aren't a magic bullet cure by
any means, but they do help when implemented. In the end, though, there's
no substitute for actually having secure code to begin with.


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:18 EST