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.
James.
-
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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:18 EST