Linux-kernel mailing list archive 2000-23,: Re: OS stopping stack buffer overflow exploits

# Re: OS stopping stack buffer overflow exploits

Robert Redelmeier (redelm@ev1.net)
Sun, 04 Jun 2000 08:42:53 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: yoann@mandrakesoft.com: "Re: OS stopping stack buffer overflow exploits"
- Previous message: kumon@flab.fujitsu.co.jp: "Re: [PATCH][CFT] dcache-ac6-D - dcache threading"
- Maybe in reply to: Robert Redelmeier: "OS stopping stack buffer overflow exploits"
- Next in thread: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"

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/

- Next message: yoann@mandrakesoft.com: "Re: OS stopping stack buffer overflow exploits"
- Previous message: kumon@flab.fujitsu.co.jp: "Re: [PATCH][CFT] dcache-ac6-D - dcache threading"
- Maybe in reply to: Robert Redelmeier: "OS stopping stack buffer overflow exploits"
- Next in thread: Khimenko Victor: "Re: OS stopping stack buffer overflow exploits"