Robert Redelmeier wrote:
> 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've always be arguing that blocking the "exec /bin/sh" (that standard
exploits do) doesn't help. You can implement a shell like thingy
inside the exploit.
So your suggestion would also help against this attack.
Until I realized that instead of doing the "int 80" to call the
kernel, the exploit will just have to do "call <syscall entry point in
libc>"
In short you'll make a change that is simply incompatible with the
current exploits, but they will be "compatible" again in a few weeks,
well before everyone has upgraded to the new kernel.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- 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