Theodore Y. Ts'o wrote in a rather different order:
>
> 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.
I fully agree. The best protection is tight code in the first place.
Thes measure are more like band-aids. I agree the adersary isn't always
stupid and can adapt. But you can certainly make it harder for him,
and more importantly, dangerous for his henchmen [skript-kiddiez]
> This doesn't help, since the call path is usually
> user-application calls glibc calls kernel system call
True. There are many ways to execute a syscall, and this
countermeasure is easily bypassed.
> 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).
This is actually a much stronger countermeasure, because stack buffer
overflow exploits must hardcode their entry point.
> 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.
No, I don't think so. I think it's much better since the logs will be
caught, hopefully on a bastion logger. Since the stack start addr would
change every time the process [re]starts, the attacker would have to
keep trying. If the randomization were over 1032 bytes (4-byte aligned
for performance) there would be 256 addrs for the attacker to try, and
on average, he'd leave 128 log entries. That should stand out.
> Unfortunately, there isn't much substitution for simply preventing
> stupid coding mistakes that allow buffer overruns in the first place.
There is no substitute for good code! But I think my other idea, limited
CS descriptors to prohibit execution on the stack, is much stronger.
The objection of stack kernel code can be fixed two ways: fix the
kernel hack, or allow Ring0 code an unlimited descriptor. Flat mode
still changes descriptors on ring transition.
-- Robert
-
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