Uninformed: Informative Information for the Uninformed

Vol 9» 2008.Jan


Introduction

Modern exploit mitigations have become formidable opponents with respect to the effect they have on reliable exploitation. Some of the more substantial modern mitigations include GuardStack (GS), SafeSEH, DEP (NX), ASLR, pointer encoding, and various heap improvements[8,9,10,15,24,3,4]. The fact that there have been very few public exploits that have been able to universally bypass all of these mitigations at once is a testament to the resilience of these techniques working in concert with one another. It is obvious that the absence of a given mitigation directly contributes to the exploitability of the associated code. Likewise, it is also well known that most mitigations have situations in which they will offer little to no protection[5,16,18,20,2,4]. For instance, in certain cases, it may be possible to perform a partial overwrite on Windows Vista to defeat ASLR due to the fact that only 15 bits of most 32-bit addresses may be affected by randomization[2,17]. Other mitigations also have situations where they may not provide adequate coverage.

Given the fact that the majority of mitigations have known limitations, it makes sense to consider where this information might be useful. In the field of program analysis, whether it be manual, static, or dynamic, the question of scoping is often pertinent. This question typically revolves around figuring out what areas of code should be reviewed and what precedence, if any, should be assigned to different regions. Typical approaches taken to accomplish this often involve identifying code that straddles a trust boundary or performs complex operations reachable from a trust boundary. However, depending on one's perspective, this type of approach is insufficient in the face of modern mitigations because it may result in areas of code being reviewed that are adequately protected by all mitigations.

To help address this perceived deficiency, this paper introduces the concept of exploitation properties and describes how they can be used to provide a better understanding of the exploitability of a system if a vulnerability is found to be present. Regions of code that are found to have a number of distinct exploitation properties may be more interesting from an exploitation standpoint and therefore may warrant additional scrutiny from a program analysis perspective. The use of exploitation properties may benefit both an attacker and a defender. For example, companies may wish to perform targeted reviews on areas of code that may be more trivially exploited in an effort to prevent reliable exploits from being released in the future. Likewise, an attacker searching for a vulnerability may wish to avoid auditing regions of code that are likely to be more difficult to exploit.

Exploitation properties represent additional criteria that can be used when attempting to better understand the security aspects of a program. Annotating regions of code with exploitation properties makes it possible to use set unions and intersections to identify the subset of interesting regions of code for a particular analysis problem. For example, an attacker may wish to determine the regions of code that may permit the use of traditional stack-based buffer overflow techniques as well as permitting a partial overwrite of a return address in order to defeat ASLR. Using these two exploitation properties as criteria, a narrowed subset can be produced which contains only those regions which meet both criteria by intersecting those regions that have both exploitation properties. For the purpose of this paper, the term narrowing is not used in the strict mathematical sense; rather, this paper uses narrowing to describe the process of constraining the scope of analysis through the use of specific criteria.

The concept of using automated analysis as a precursor to more strenuous program analysis is certainly not new. There have been many tools ranging from the simple detection of calls to strcpy to much more sophisticated forms of static analysis. Still, the use of exploitation properties can be seen as an additional set of data points which may be useful in the context of program analysis given the hypothesis that most reliably exploitable security vulnerabilities are being pushed into areas of code that are less affected by mitigations.

The concept of exploitation properties is presented as follows. §2 categorizes and defines a limited number of concrete exploitation properties. §3 provides a concrete example of using exploitation properties to help identify the function that contained the ANI vulnerability. §4 describes some potential ways in which exploitation properties can be applied. §5 gives a brief description of future work involving exploitation properties.