Reversing Microsoft patches to reveal vulnerable code

[Nytro]

Reversing Microsoft patches to reveal vulnerable code

Harsimran Walia

Computer Security Enthusiast

The paper would try to reveal the vulnerable code for a particular disclosed vulnerability, which is the

first and foremost step for making undisclosed exploit and patch verification. The process used herein

could be used to create vulnerability based signatures which are far better than exploit signatures.

Vulnerability signature is a superset of all the inputs satisfying a particular vulnerability condition

whereas exploit based signature would only cater to one type of input satisfying that vulnerability

condition. This paper would try to pin point the vulnerable code and the files in Microsoft products by

reverse engineering the Microsoft patches.

The method used would be to take a binary difference of the file which was patched taken at two

different instances, one is the most recent file before patching and the second is after applying the

patch but finding the two files is in itself another problem. Windows now releases two different versions

of patches, GDR (General distribution) which contains only security related updates and the other QFE

(Quick Fix Engineering) or LDR (Limited Distribution Release) which has both security related and

functional updates. The problem addressed is that the versions of the two files to be compared should

match that is either both should be GDR or LDR. The file after patching can be obtained by extracting

the patch of the considered vulnerability. The second file to be compared with a matching version with

the first one could be extracted from some other vulnerability patch addressing the issue with the same

software disclosed just before the vulnerability considered. The process of extraction of files from

patches differs in Vista and Windows 7 from the traditional way used in Windows XP.

After obtaining the correct files to be compared, the next step would be to get a binary difference

between the files which can be done very easily and effectively with the use of a tool called DarunGrim.

The tool provides a well illustrated difference between the subroutines in the term of percentage match

between them. Subroutines from both the files can be viewed in graph mode and can be compared to

find the vulnerability. The change in the code is done to fix that particular vulnerability which may be

removal of a piece of code and addition of another. Another problem arises at this point is that compiler

optimizations happen every-time a code is compiled, so if both the files are compiled with different

compilers or compiler versions, they would have different compiler optimizations and that would also

show up as a change in code. Simple Instruction reordering keeps happening over different releases

which give rise to another problem as when only the instructions are reordered, still it would show up

as changed code. The code change in one of the functions out of several functions in the file before

applying the patch would be the vulnerable code. From here knowledge of the reverse engineer would

come into play as how effectively and fast he can find the vulnerability from the code shown as being

changed from the previous file. Till now the process used was static analysis but from now onwards

dynamic analysis would be used as breakpoints could be set at these changed functions and run the

software. When a breakpoint is hit we can check in which of the functions is user input being dealt.

Obtaining all this information can then be used to write an exploit.

This process of reversing the patch and finding the details about the vulnerability would definitely help

in creating vulnerability signatures.

Download:

http://nullcon.net/nullcon2011presentation/harsimranwalia_nullcon.pdf