Acidus wrote:

In the automatic patch-based exploit generation problem, we are given two versions of the same program P and P' where P' fixes an unknown vulnerability in P. The goal is to generate an exploit for P for the vulnerability fixed in P'. More formally, we are given a safety policy F, and the programs P and P'. The purpose of F is to encode what constitutes an exploit. Our goal is to generate an input x such that F(P(x)) = unsafe, but F(P′(x)) = safe.

... ... !!!

There is something humbling about seeing hours work (reading the Microsoft security bulletin, using IDA and BinDiff, discovering the security changes, performing the needed "magic" like unicode evasion, no null's etc) reduced to a math equation.

This article seems to have stirred up a bit of drama. I finally got time to read it this evening. These people have developed a powerful toolset that can be used to achieve some very interesting results, but I also think that what they've demonstrated here falls far short of what their abstract claims.

Basically, you get the impression that they can take a patch diff, pop it in a black box, and pull a program out the other side that can be used to launch remote code execution attacks. They then go on to assume that attackers can use tools like this to instantly produce exploits from a patch, and discuss the implications of that for patch distribution strategies. But thats not what they've produced.

What they've produced takes a patch diff as well as either input sufficient to reach the vulnerable code, or information about the place in the binary where the specific input values that exploit the vulnerability are read in, and produces permutations of that input which would be rejected by the patched version of the code.

In my view the time spent determining what sort of input can reach the vulnerable code (what inputs not what values of those inputs), and more importantly the time spend actually exploiting the vulnerability to gain unauthorized code execution, contribute more to the time required to produce working exploits from patch diffs than the part of the problem that has been solved by this paper, and so their conclusions about the impact of this result on the time from patch distribution to exploit distribution is not correct.

This tool could be helpful in analyzing vulnerabilities where a great deal of permutation occurs to data before the vulnerable code is reached, but it does not result in automatic generation of anything from patches alone, and it does not generate what I would call an exploit.

The underlying toolset, however, is very interesting. Its basically a computer that reads assembly code. You can program it to answer questions about that code. There are many questions that one could ask about binary code that would be helpful in vulnerability research and analysis beyond those envisioned here. Its a shame that these tools seem to not be available to the public.

RE: Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications