Abstract

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 everytime a code is compiled, so if both the files are compiled with different compilers or compiler versions, they would have different compiler optimisations and that would also show up as a change in code. Simple Instruction reordering keeps happening over different releases which gives 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.