Reversing patches to create exploits is nothing new, and it tends to occupy the time of a lot of security researchers around the 2nd Tuesday of every month, but an interesting research paper was published recently from a few graduate students at CMU, Berkeley, and Pittsburgh that offers a new twist on an old topic. In it, the group describes techniques to automatically generate exploit code based on the patch set. The approach is interesting, essentially they have developed a set of algorithms, using off the shelf tools that will generate a set of inputs that was accepted before the patch, and a set of inputs that are accepted after the patch. The difference between the sets is the “exploit” set, and the process described is probably very good at that. But there is a lot more to exploit development than simply knowing the input, this will aid in the process though.
One thing that the authors point out, but most of the reports on it don’t is that this only works with a subset of integer overflow/underflow type vulnerabilities, and there are still a large number of other vulnerabilities classes that this research doesn’t currently apply to. The group does hope to continue research towards other types of vulnerabilities, but the problem space gets much larger and more complex with other classes of vulnerabilities, so an automated tool for other classes is still quite far away. But you can’t blame the guys for being proud of their research.
This paper does however bring up on old issue worth discussing again, patch distribution. Currently the way patches are distributed there is a significant time gap in being applied to the first and “last” system, and even more so with critical systems and networks where a patch may have to be vetted internally for quite some time before being applied. According to Microsoft, it takes about 24 hours for Windows Update to see 80% of the unique IPs that it will check for a patch, and with that sort of time lag along with good tools a significant number of these systems can be compromised by a wormable flaw.
A few solutions are mentioned, and have been discussed in the community from time to time, from patch encryption, to patch obfuscation, to peer to peer distribution system, and all sorts of other things. There isn’t a clear solution and they all bring up their own benefits, liabilities, and policy issues, and it remains to be seen what mechanisms, if any, major patch distributors like Microsoft and Oracle will choose.