Test Case

The author developed an analysis tool as an extension to Microsoft's Phoenix framework in order to test the ideas described in this paper[12]. Unfortunately, the current release (July 2007 SDK) of Phoenix requires private symbol information for native binaries. This limitation prevented the author from being able to run the analysis tool across the vulnerable version of user32.dll. In lieu of this ability, the author chose to generate a binary containing test cases that closely mirror the form of the function containing the ANI vulnerability.

Using these test cases, the author used the features provided by the analysis tool to determine the exploitation and vulnerability properties described in the previous section and to identify the resulting subset of functions meeting all criteria. This was accomplished by first attempting to identify the subset of functions that do not contain GS within the scope of the target binary. After identifying the subset of functions without GS, a second subset was taken which consists of the functions that pass a pointer to a stack-allocated local variable as a parameter to a child routine. This was accomplished by using Phoenix's static single assignment (SSA) and alias implementations to collect the requisite data flow information[12,25]. Using this data flow information, it is possible to perform backwards data flow analysis to determine the potential storage location of the parameter being passed at each point along a given data flow path starting from the operand associated with a parameter at a call site. The analysis terminates either when a fixed point is reached or when it is determined that a pointer to a stack-allocated variable could be passed as the parameter.

While the previous section described the potential for using the partial overwrite exploitation property to detect the function containing the ANI vulnerability, it is not possible to create a meaningful parallel between the test binary and that of the ANI vulnerability. This is due in part to the fact that while it would certainly be possible to artificially place a useful opcode at a specific location in the test binary, it would not add any value beyond showing that it is possible to detect useful opcodes within the same 16-page aligned region as the caller of a given function. The author feels that this point is somewhat moot given the fact that it has already been proven that a partial overwrite can be used with the ANI vulnerability[6]. The only additional benefit that it could offer in this case would be to help further constrain the resultant set size. However, without being able to run this analysis against the vulnerable version of user32.dll, it is not possible to draw meaningful conclusions at this point in time.