Automatic exploit generation

| Comments (1) | SYSSEC
In any cost/benefit analysis of vulnerability policy, we have to factor in the impact of exploitation that results from fixing the vulnerability. In particular, if you provide a full description of the vulnerability at the same time as you patch it, then it's generally easy for an attacker to construct an exploit. Since patch distribution and installation can take between hours and weeks, this gives the attacker a significant window of opportunity to mount attacks before people patch their machines.

A natural response to this is to simply release patches but not descriptions of vulnerabilities, on the theory that the patches disclose less. It's obvious that this isn't true with open source systems, since it's trivial to examine a given change and determine what attack it's designed to stop, but there have also been reports that attackers reverse engineer binary patches (in some cases within hours) to construct exploits. In this year's USENIX, Brumley et al. take this to its logical conclusion and describe a technique for automatically generating exploits based on patches. This doesn't really change the situation much as far as I can tell; it was widely believed this was possible, and while this tool takes seconds to minutes instead of hours, it was never plausible that you'd get complete patch deployment inside of 12-24 hours anyway, so shaving a few hours off the attacker time may not make much of a difference.

The authors describe a number of techniques (obfuscation, encrypted patches, P2P patch distribution) one might imagine using to reduce the impact of fast attack generation, and conclude (correctly IMO) they're not that likely to work. As I understand it, the critical path item in patch installation for important systems isn't obtaining the patch but testing it on sacrificial systems to make sure it doesn't introduce instability, and that creates an inherent lag that probably can't be removed with a new distribution method.

Another alternative (though it goes against the trend in recent practice) is to be less aggressive about releasing patches for vulnerabilities that haven't already been disclosed. The faster that attackers can respond to new vulnerabilities by comparison to defenders, the more that fixes released in an orderly fashion look like zero-day vulnerabilities and so the less attractive it looks to fix vulns that aren't generally known (Res04 has some analysis of this issue.)


The other option is, IMO, vulnerability signature filters. Some filters which are designed to target the exploitation of the vulnerability, but which can be painlessly backed out.

Thus make it POSSIBLE to do "Patch & Pray" with less damage when something goes wrong.

Also, such filters could be small and light, so you could do auto-distribution in the seconds-to-minutes timescales needed in the world of automatic exploit generation.

Leave a comment