Date: Sat, 03 Jun 2000 21:06:46 -0500
From: Robert Redelmeier <redelm@ev1.net>
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.
This doesn't help, since the call path is usually
user-application calls glibc calls kernel system call
So what the kernel will see is a return address from inside glibc.
A generic problem with this class of countermeasures is that it only
buys you at most a modest increase of security, since if you can control
the return address of the glibc return, you can just point it at the
"exec /bin/sh" instruction inside glibc, or any number of other damaging
parts of the program. This in turn can be prevented by randomizing the
starting address of glibc, but this doesn't help you against known code
segments inside attacked program.
You can also get an equivalent amount of protection (i.e., preventing
execution on the stack) by simply randomizing the starting stack
address, so the adversary is forced to guess the right return address.
(This can be done in crt0, without needing kernel mods).
Yes, if you don't mind continually crashing the executable (for example,
if it's run out of /etc/inetd.conf, and you don't mind lots of errors in
/var/log/messages), you can keep guessing until you get the stack
address right. But then again, the same attack (of continueing to guess
and generating core dumps until you can get in) can be applied against
the countermeasure of randomizing the glibc address relocation address.
So again, it's the equivalent level of protection.
Unfortunately, there isn't much substitution for simply preventing
stupid coding mistakes that allow buffer overruns in the first place.
An important lesson to remember when you try to come up with security
systems is that the adversary is (a) not necessarily stupid, and (b) can
adapt to your countermeasures.
- Ted
-
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