MS patch system poses 'significant risk', say researchers

The fix could automate production of the attack

The automatic patch-based exploit generation (APEG) requires that the differences in patched and unpatched binaries be found first. The researchers used eEye's Binary Diffing Suite (EBDS), but others - such as the well-known bindiff - could be used as well. The researchers then tested a number of heuristics for determining which of the changes actually fixed the flaw and discovered that, frequently, the smallest changes typically acted as a reliable marker for the location of a new sanity check.

Using principles from automated test-case generation processes, the four researchers modeled the flow of the program and used an intermediate language, known as Vine, to express the sequence of instructions that lead to the vulnerable code being executed. Knowing the execution path allows the researchers to place constraints on the inputs that could trigger the exploitation of the vulnerability, significantly reducing the number of possible variables through which the APEG has to search. The researchers used a combination of static analysis, where a single execution of the program is used to determine program flow, and dynamic analysis, where an abstract graph represents all the control-flow possibilities.

The result is a constraint formula, the solution to which are candidate exploits. The possible exploits can then be tested to determine which ones are true exploits for the vulnerability.

Brumley and his colleagues used the automatic patch-based exploit generation (APEG) system to create exploits from five recent Microsoft patches. After the differences between patched and unpatched binaries were found, the system took as little as six seconds to, at most, about three minutes to find an exploit.

"Specific types of attacks, such as control hijack, are just an extra condition on the set of all possible exploits for a single bug," Brumley said. "We can include such conditions in our approach."

Even though the system does not create fully weaponize exploits and may not work for all types of vulnerabilities, it does show that developing exploits from patches could be done in minutes. Yet, Microsoft has not taken adequate steps to make such attempts more difficult, Brumley said. The researchers suggested possible avenues that Microsoft could pursue to increase the likelihood that customers received patches before attackers could reverse engineer them, including obfuscating the code, encrypting the patches and waiting to distribute the key simultaneously, and using peer-to-peer distribution to push out patches faster.

"There are ways that Microsoft could distribute patches and not tip off the attackers," Brumley said.

Microsoft declined to comment for this article, except to say that the company is reviewing the research.

Some security experts doubt whether the APEG process could result in weaponized exploits quickly enough to pose a threat.

"Every patch from Microsoft has differences," Errata Security's Graham said. "There is nothing that can really generalize across Microsoft patches. There are a lot of possibilities for diagnostic tools that will shorten the time (to create an exploit), but that time will never go to zero."

Yet, even with his doubts, Graham stressed that the trend is clear and agreed that Microsoft should be thinking about making patches more difficult to exploit.

"You (developers) should generally be thinking about this," he said. "As reverse engineering gets more prevalent in the industry, you should be generally thinking about how to change your code to make it harder to do."

Brumley and his colleagues will present the paper at the annual IEEE Symposium on Security and Privacy in May. The co-authors of the paper are Pongsin Poosankam of Carnegie Mellon University, Dawn Song of University of California at Berkeley, and Jiang Zheng of University of Pittsburgh.

This article originally appeared in Security Focus.

Copyright © 2008, SecurityFocus