Detection

The ease of exploitability associated with the ANI vulnerability makes it an obvious candidate for study with respect to the exploitation properties that have been described in this paper. It should be possible to use extremely simple criteria to accomplish two things. First, the criteria must identify the LoadAniIcon function. Second, the criteria should be unique enough to limit the size of the narrowed subset. Reducing the subset size is beneficial as it may permit the use of more complex program analysis tools which can further constrain or explicitly identify instances of vulnerabilities. Determining the specific criteria that is needed to identify the LoadAniIcon function can help illustrate how one can make use of exploitation properties. Given the description of the ANI vulnerability, one can easily deduce some of the more interesting properties that it has.

An exploitation property that one might immediately observe is that the LoadAniIcon function does not make use of GS (§2.4.1). This makes it possible to define criteria which states that only functions that have not been compiled with GS should be considered. Functions that have been compiled with GS are inherently less interesting for the purpose of this exercise due to the fact that they are less likely to contain exploitable vulnerabilities.

A second property that the ANI vulnerability had with regard to exploitation was that it was possible for an attacker to make use of a partial overwrite to defeat ASLR. The exploitation property described in §2.4.2 illustrates how one can make this determination statically. In the case of the ANI vulnerability, a partial overwrite can be performed by making use of a jmp [ebx] that is located within the same 16-page aligned region as the caller of LoadAniIcon. Thus, any functions that could potentially make use of a partial overwrite can be used as additional criteria.

At this point, a subset can be produced that is constrained to the regions of code that are annotated with the GS and partial overwrite exploitation properties. It is possible to further refine the set of functions that should ultimately be considered by studying the form that the ANI vulnerability took. The first point to note is that the stack-based buffer overflow occurred when writing beyond the bounds of a struct that was allocated on the stack. Furthermore, the overflow did not actually occur in the immediate context of the LoadAniIcon itself. Instead, the overflow was triggered by passing a pointer to the stack-allocated struct as a parameter when calling the function ReadChunk.

Based on these data points it is possible to define a third criteria. In this case, the third criteria is not an exploitation property but is instead an example of a vulnerability property. While not discussed in detail in this paper, many examples of vulnerability properties exist, though perhaps not categorized as such. A vulnerability property can be thought of as an annotation that illustrates whether or not a region of code has a form that is similar to that seen in vulnerabilities or has the potential of being a vulnerability. The complexity of a vulnerability property, as with the complexity of an exploitation property, can range from highly sophisticated to very simplistic.

For the purpose of this paper, a vulnerability property can be used that is very simple and imprecise but nevertheless effective at further narrowing the set of functions that should be reviewed. This property is based on whether or not a function passes a pointer to a stack-allocated variable as a parameter to a child function. This property is directly derived from the general form that the ANI vulnerability takes. At a minimum, a region of code that matches this form suggests that a vulnerability could be present.

Using these three properties, it should be possible to easily identify both the function that contains the ANI vulnerability as well as other functions that could contain similar vulnerabilities. However, it is important to note that this process does not produce functions that definitely have vulnerabilities. This can be plainly seen by the fact that both the vulnerable and fixed versions of the LoadAniIcon should be detected by the criteria described above. While this may seem to run counter to the purposes of this paper, it is important for the reader to remember that the goal of using these exploitation properties is not to identify specific instances of vulnerabilities. Instead, the goal is to identify regions of code that might warrant additional scrutiny due to the relative ease with which a vulnerability could be exploited if one is found to be present.