Re: Theo's presentation on exploit prevention

["Kurt Seifried" <listuser () seifried org>]

Seen it, good presentation, but if you run current and keep up to date on 
the security discussion side of things it's nothing to new (a lot of this 
stuff dates back 1-3 years). Do these changes 100% stop attack classes? 
Probably not, some for example:

http://cvs.openbsd.org/papers/auug04/mgp00004.html
Solution: a random-sized gap at top of stack (b-byte aligned)

This makes life a whole heck of a lot harder (you go from 1 in 1 to 1 in 
32768, ignoring birthday paradox and what not I like the second set of odds 
better), now if the attacker has local access and can keep beating on it, 
chances are they may get lucky at some point. For a remote attacker trying 
to bypass this, assuming the service crashes each time they exploit it wrong 
(likely but not certain) life just got a whole lot harder, PLUS the remote 
admin is likely to notice something wonky is going on when a service keeps 
crashing.

Privilege seperation, again not 100% protection, but when you go from 27,000 
lines of code to 2500 lines of code (or was it 25,000 and 2700, either way) 
running as root you have a whole lot less code to audit and harden.

W^X, Propolice, random library mapping, etc. All these changes serve to make 
buffer overflows much harder, an attacker at home with a 3.5 box can make an 
exploit that works on their system, but on my system it stands a good chance 
of either failing, or simply crashing the application in question, the 
chances of it executing the code have gone from 1:1 (based on a working 
exploit on the user's machine) to 1:large number. Even for a targeted attack 
with multiple attempts you're relatively safe.

All I know for sure is that the number of remote and local exploits in 
OpenBSD (default install and otherwise) has dropped significantly over the 
years, to the point now where I would be quite surprised if someone managed 
to make exploit code that worked reliably for a local or remote hole (even 
with everything enabled, i.e, dhcp client, sendmail, etc.).

Kurt Seifried, kurt () seifried org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave