Improving Software Security Analysis using Exploitation Properties12/2007skape mmiller@hick.org AbstractReliable exploitation of software vulnerabilities has continued to become moredifficult as formidable mitigations have been established and are now includedby default with most modern operating systems. Future exploitation ofsoftware vulnerabilities will rely on either discovering ways to circumventthese mitigations or uncovering flaws that are not adequately protected.Since the majority of the mitigations that exist today lack universal bypasstechniques, it has become more fruitful to take the latter approach. It is inthis vein that this paper introduces the concept of exploitation propertiesand describes how they can be used to better understand the exploitability ofa system irrespective of a particular vulnerability. Perceived exploitabilityis of utmost importance to both an attacker and to a defender given thepresence of modern mitigations. The ANI vulnerability (MS07-017) is used tohelp illustrate these points by acting as a simple example of a vulnerabilitythat may have been more easily identified as code that should have receivedadditional scrutiny by taking exploitation properties into consideration.1) IntroductionModern exploit mitigations have become formidable opponents with respect tothe effect they have on reliable exploitation. Some of the more substantialmodern mitigations include GuardStack (GS), SafeSEH, DEP (NX), ASLR, pointerencoding, and various heap improvements[8, 9, 10, 15, 24, 3, 4]. The factthat there have been very few public exploits that have been able touniversally bypass all of these mitigations at once is a testament to theresilience of these techniques working in concert with one another. It isobvious that the absence of a given mitigation directly contributes to theexploitability of the associated code. Likewise, it is also well known thatmost mitigations have situations in which they will offer little to noprotection[5, 16, 18, 20, 2, 4]. For instance, in certain cases, it may bepossible to perform a partial overwrite on Windows Vista to defeat ASLR due tothe fact that only 15 bits of most 32-bit addresses may be affected byrandomization[2, 17]. Other mitigations also have situations where they maynot provide adequate coverage.Given the fact that the majority of mitigations have known limitations, itmakes sense to consider where this information might be useful. In the fieldof program analysis, whether it be manual, static, or dynamic, the question ofscoping is often pertinent. This question typically revolves around figuringout what areas of code should be reviewed and what precedence, if any, shouldbe assigned to different regions. Typical approaches taken to accomplish thisoften involve identifying code that straddles a trust boundary or performscomplex operations reachable from a trust boundary. However, depending onone's perspective, this type of approach is insufficient in the face of modernmitigations because it may result in areas of code being reviewed that areadequately protected by all mitigations.To help address this perceived deficiency, this paper introduces the conceptof exploitation properties and describes how they can be used to provide abetter understanding of exploitability of a system if a vulnerability is foundto be present. Regions of code that are found to have a number of distinctexploitation properties may be more interesting from an exploitationstandpoint and therefore may warrant additional scrutiny from a programanalysis perspective. The use of exploitation properties may benefit both anattacker and a defender. For example, companies may wish to perform targetedreviews on areas of code that may be more trivially exploited in an effort toprevent reliable exploits from being released in the future. Likewise, anattacker searching for a vulnerability may wish to avoid auditing regions ofcode that are likely to be more difficult to exploit.Exploitation properties represent additional criteria that can be used whenattempting to better understand the security aspects of a program. Annotatingregions of code with exploitation properties makes it possible to use setunions and intersections to identify the subset of interesting regions of codefor a particular analysis problem. For example, an attacker may wish todetermine the regions of code that may permit the use of traditionalstack-based buffer overflow techniques as well as permitting a partialoverwrite of a return address in order to defeat ASLR. Using these twoexploitation properties as criteria, a narrowed subset can be producedwhich contains only those regions which meet both criteria by intersectingthose regions that have both exploitation properties. For the purpose ofthis paper, the term narrowing is not used in the strict mathematicalsense; rather, this paper uses narrowing to describe the process ofconstraining the scope of analysis through the use of specific criteria.The concept of using automated analysis as a precursor to more strenuousprogram analysis is certainly not new. There have been many tools rangingfrom the simple detection of calls to strcpy to much more sophisticated formsof static analysis. Still, the use of exploitation properties can be seen asan additional set of data points which may be useful in the context of programanalysis given the hypothesis that most reliably exploitable securityvulnerabilities are being pushed into areas of code that are less affected bymitigations.The concept of exploitation properties is presented as follows. Section 2categorizes and defines a limited number of concrete exploitation properties.Section 3 provides a concrete example of using exploitation properties to helpidentify the function that contained the ANI vulnerability. Section 4describes some potential ways in which exploitation properties can be applied.Section 5 gives a brief description of future work involving exploitationproperties.2) Exploitation PropertiesExploitation properties describe the ease with which an arbitraryvulnerability might be exploited. An understanding of a system's perceivedexploitability can provide useful insights when attempting to establish therisk factors associated with it. An example of this can be seen in threatmodeling where the DREAD model of classifying risk includes a high-levelevaluation of exploitability as one of the risk factors[14]. It is importantto note that exploitation properties do not provide any indication that avulnerability exists; instead, they are only meant to convey information abouthow easily a vulnerability could be exploited. The concept of an exploitationproperty can be broken into different categories which are tied to theconfiguration or context that the property is associated with. Examples ofthese categories include platforms, processes, binary modules, functions, andso on.The following subsections provide concrete examples to better illustrate theconcept of an exploitation property. These examples are given by showing whatimplications a property has with respect to exploitation as well as how aproperty might be derived. It should be noted that the examples given in thispaper do not represent a complete, exhaustive set of exploitation properties.2.1) Platform Properties Exploitation properties associated with a platform are meant to illustrate howeasily a vulnerability may be exploited when a given platform configuration,such as the operating system or architecture, is used. For example, Windows2000 does not include support for enforcing non-executable pages. Thisimplies that any vulnerability found within an application that runs in thecontext of the Windows 2000 platform may be exploited more easily. Anunderstanding of exploitation properties that are associated with a platformmay be useful when attempting to assess the risk of applications that mightrun on multiple platforms. There are many other examples of exploitationproperties that are tied to platforms. In order to limit the scope of thisdocument, platform exploitation properties are not discussed at length.2.2) Process Properties Process exploitation properties carry some information about how easilyvulnerabilities found within the context of a running process may beexploited. For example, Internet Explorer running on 32-bit versions ofWindows Vista do not make use of hardware-enforced DEP (NX) by default. Thismeans that any vulnerabilities found within code that runs in the context ofInternet Explorer will not be protected by non-executable regions. Anunderstanding of exploitation properties that are associated with a processcontext can help to provide a better understanding of the risks associatedwith code that may run in the context of a given process. In order to limitthe scope of this document, process exploitation properties are not discussedat length.2.3) Module PropertiesModule exploitation properties are used to illustrate the effect that aparticular binary module has on ease of exploitation. This category ofproperties is useful when attempting to identify binaries that may be moreeasily exploited if a vulnerability is found within them or in code thatdepends on them. This subsection describes two examples of moduleexploitation properties.2.3.1) No Support for ASLRWindows Vista was the first major release of Windows to include a built-inimplementation of Address Space Layout Randomization (ASLR)[15,24]. In orderto head off potential application compatibility issues, Microsoft chose tomake ASLR an opt-in feature by requiring binaries to be compiled with a newcompiler switch (/dynamicbase)[21]. This compiler switch is responsible forsetting a bit (0x40) in the DllCharacteristics that are defined within abinary. If this bit is set, the Windows kernel will attempt to randomize thebase address of the binary when it is mapped into memory the first time. Ifthe bit is not set, the binary will not have its base address randomized,although it could be relocated in memory if the binary's preferred region isalready occupied by another allocation. As such, any binary that does notsupport ASLR may be mapped at a predictable location within a process addressspace at execution time. This can allow an attacker to make assumptions aboutthe address space which may make exploitation easier if a vulnerability isfound within any code that is mapped into the same address space as the moduleof interest.2.3.2) No Support for SafeSEHWith Visual Studio 2003, Microsoft introduced a compile-time change known asSafeSEH which attempts to act as a mitigation for the SEH overwrite attackvector[5,9]. SafeSEH works by adding a static list of known good exceptionhandlers that are considered valid as metadata within a given binary.Binaries that support SafeSEH allow the exception dispatcher to performadditional checks when dispatching exceptions. The most important checkinvolves determining if an exception handler that is found to exist within themapped region of a given binary is actually considered to be one of the safeexception handlers. If the exception handler is not a safe exception handler,the exception dispatcher can take steps to prevent it from being called. Thisbehavior works to mitigate the potential exploitation vector.In order to communicate this information to the exception dispatcher, modernPE files include fields in the load config data directory which hold theoffset of the safe exception handler table and the number of elements foundwithin the table. The load config data directory contains meta data that isuseful to the dynamic loader such as information about safe exceptionhandlers, the module's global security cookie address, and so on[13]. Thefollowing output from dumpbin.exe illustrates what this might look like: 310751E0 Safe Exception Handler Table 1 Safe Exception Handler CountSafe Exception Handler Table Address -------- 310357D1 __except_handler4Unfortunately, as with ASLR, the benefits offered by SafeSEH are not completeunless every binary that is loaded into an address space has been compiled tomake use of SafeSEH. If a binary has not been compiled to make use ofSafeSEH, an attacker may be able to use any address found within the binary'smemory mapping as an exception handler in conjunction with an SEH overwrite.2.4) Function PropertiesFunction exploitation properties convey information about how a functioncontributes to the exploitability of an application. For example, a functionmight make it possible to use certain exploitation techniques that mightotherwise be prevented if mitigations were present. Alternatively, a functionmight simply assist in the exploitation process. Function exploitationproperties are especially useful because they provide more detailedinformation than exploitation properties that are derived from the platform,process, or module context.2.4.1) Absence of GuardStackThe GuardStack (GS) support included with versions of the Microsoft VisualStudio compiler since 2002 offers a compile-time mitigation to traditionalstack-based buffer overflows[23]. It supports this through a combination of arandom canary inserted into a stack frame at runtime and an intelligent stackframe layout algorithm. The random canary is pushed onto the stack when afunction is called and then popped off the stack and validated prior tofunction return. If the canary does not match the expected value, it isassumed that a stack-based buffer overflow occurred and that the processshould be terminated.Since the initial release of GS support a number of techniques have beendescribed that could be used to bypass or weaken it[5, 16, 20]. While thesetechniques were at one time useful or have not yet been fully realized, theauthor assumes that most would agree that the GS implementation provided bythe most recent compiler is robust (with the exception of SEH). There iscurrently no publicly known universal bypass technique for GS that the authoris aware of. Given this assumption, functions that are protected by GS becomeless interesting from the standpoint of identifying stack-based bufferoverflows. On the other hand, functions that are not protected by GS caninstantly be qualified as interesting targets for review. This is especiallytrue with binaries that have been compiled with GS support but contain anumber of functions that the compiler has chosen not to compile with GSprotections. This choice is made by taking into account certain conditions suchas the presence or absence of local variables that are declared as fixed-sizearrays.As previous research has illustrated[27], it is possible to identify functionsthat have not been compiled to use GS through the use of simple staticanalysis tools. It is also possible to further refine the approachesdescribed in previous research if one has symbols and one assumes that themost recent compiler was used. This can be accomplished by analyzing the callgraph of an executable and noting the set of functions that do not callsecuritycheckcookie. Considered another way, the same set of functions can beidentified by taking the set of all functions contained within a binary lessthe subset that call securitycheckcookie. The set of functions that isidentified by either approach can be annotated with an exploitation propertythat indicates that they may contain stack-based buffer overflows that wouldnot be hindered by GS.It may also be prudent to take the compiler version that was used intoconsideration when analyzing binaries. This is important due to the fact thatolder versions of the compiler used a GS implementation that could betrivially defeated in certain circumstances[16]. For example, previous versionsof GS did not layout the stack frame in a manner that would prevent anattacker from overwriting other local variables and function arguments. Inscenarios where this occurred and an overwritten local variable or parameterwas dereferenced (such as by invoking a function pointer), the mitigationoffered by GS would be meaningless. Thus, a secondary exploitation propertycould involve identifying functions where attacks such as the one describedabove could be possible.2.4.2) Partial Overwrite FeasibilityOne of the unique consequences of implementing Address Space LayoutRandomization (ASLR) on Windows is the limitation that the system allocationgranularity imposes on the number of bits that can be randomized within mostmemory allocations. In particular, the allocation granularity used by Windowsenforces strict 16-page alignment for the base addresses of most memorymappings in user-mode. This restriction means that it is only possible tointroduce entropy into the low 15 bits of the high-order 16 bits of a 32-bitmemory mapping[17]. While this may sound odd at first glance, the high-order twobits are not randomized due to the divide between kernel and user-mode. Thisassumes that a machine is booted without /3GB. The low-order 16 bits remainunchanged relative to the high-order bits. This caveat means that it may bepossible to perform a partial overwrite of an address and thus bypass thesecurity features offered by ASLR[2]. However, the ability to perform a partialoverwrite also relies on the presence of useful code or data within a regionthat is relative to the address that is being overwritten.To visualize how this type of information might be useful, consider a scenariowhere an attacker is performing a partial overwrite of a return address on thestack. In this situation, it is often necessary for one or more usefulopcodes to be present at an address that is 16-page relative to the returnaddress. For example, consider a scenario where the function may have avulnerability that would permit a partial overwrite. In this example, iscalled by and . In order to permit the use of a partial overwrite, a usefulopcode must be found within the same 16-page aligned region that either orreside on. If a useful opcode is present, an exploitation property can beattached to in order to indicate that a partial overwrite may be feasible dueto the presence of a useful opcode within the same 16-page aligned region aseither or . For example, consider the following pseudo-disassemblyillustrating a case where the call f instruction in is on the same 16-pageregion as a useful opcode:... useful jmp on same 16-page region 0x14c1XXXX0x14c1fc04 jmp esp... entry point to h()0x14c1a910 push ebp0x14c1a911 mov ebp, esp0x14c1a914 call f... entry point to y(), not on same 16-page region0x137f44c8 push ebpWhile this captures the basic concept, a better approach might be to view abinary in a different way. For example, consider the following approach todrawing the same conclusion: for each code region that contains a usefulopcode, identify the subset of functions that are called from call siteswithin the same 16-page aligned region as the useful opcode. This has theeffect of annotating all of the child functions that could potentiallyleverage a partial overwrite of the return address with respect to aparticular collection of opcodes.One important point that must be made about this exploitation property is thatis entirely dependent upon the definition of "useful code or data".Exploitation is very much an art and it goes without saying that attempting toconstrain the approaches that an attacker might make use of is likely to befolly. However, defining a known-set of useful opcodes and using that set asa base with which to draw the above conclusion can be said to be better thannot doing so at all.2.4.3) Function or Parent Registers an Exception HandlerOne of the unique exploitation vectors that exists in 32-bit programs that runon Windows is known as an SEH overwrite[5]. An SEH overwrite makes it possibleto gain control of execution flow by overwriting an exception registrationrecord on the stack. From an exploitation perspective, the act of registeringan exception handler within a function opens up the possibility of making useof an SEH overwrite. Since exception handlers are chained, the act ofregistering an exception handler also implicates any functions that arechildren of a function that registers the exception handler. This makes itpossible to define an exploitation property that illustrates the possibilityof an SEH overwrite being abused within the scope of a specific set offunctions. Detecting this property can be as simple as signaturing thecompiler generated code that is used to generate and register an exceptionhandler within a function. An example of two functions, and , that wouldmeet this criteria can be seen below:void f() { __try { g(); } __except(EXCEPTION_EXECUTE_HANDLER) { }}void g() { ...}In addition to this information being useful from an SEH overwriteperspective, it may also benefit an attacker in situations where an exceptionhandler simply swallows any exceptions that are dispatched without crashingthe process[1]. In the example given above, any exception that occurs in thecontext of will be swallowed by without necessarily crashing the process.This behavior may allow an attacker to retry their exploitation attemptmultiple times, thus enabling a bruteforce attack that would otherwise not befeasible. This can make defeating ASLR more feasible.2.4.4) Function is an Exception HandlerThe introduction of SafeSEH as a modern compile-time mitigation has caused theparticulars of how exception handlers are implemented to become moreinteresting. This has to do with the fact that SafeSEH restricts the set ofexception handlers that may be called by the exception dispatcher to thosethat are specified as being valid within the scope of a given binary. Asdiscussed previously in this paper, SafeSEH prevents traditional SEHoverwrites from being able to use any address as the overwritten exceptionhandler. While this is effective in its primary intent, there is still thepossibility that a valid exception handler can be abused to make exploitationmore feasible[1]. This scenario is restricted to EH3 and prior exceptionhandlers as EH4 includes a check of a cookie before dispatching exceptions.As such, it may be useful to flag the regions of code that are associated withEH3 and prior exception handlers, including language-specific exceptionhandlers, as being potentially interesting from an exploitation perspective.Unfortunately, as with ASLR, the benefits offered by SafeSEH are not completeunless every binary that is loaded into a process address space has beencompiled to make use of SafeSEH. If a binary has not been compiled to makeuse of SafeSEH, an attacker may be able to use any address found within thebinary's memory mapping as an exception handler in the context of an SEHoverwrite. This may make exploitation more feasible.3) Case Study: MS07-017The animated cursor (ANI) vulnerability was discovered by Alexander Sotirov inlate 2006 and patched by Microsoft with the MS07-017 critical update in April,2007 . Apart from being a client-side vulnerability that was exposed throughweb-browsers and other mediums, the ANI vulnerability was one of the firstnotable security issues that affected Windows Vista. It was notable due tothe simple fact that even though Microsoft had touted Windows Vista as beingthe most secure operating system to date, the exploits that were released forthe ANI vulnerability were very reliable. These exploits were able to ignoreor defeat the protections offered by mitigations such as GS, DEP, and evenVista's newest mitigation: ASLR.To better understand how this was possible it is important to dive deeper intothe details of the vulnerability itself. gives a brief description of theANI vulnerability and some of the techniques that were used to successfullyexploit it. Following this description, illustrates how exploitationproperties, in combination with another class of properties, can be used todetect functions that may contain vulnerabilities similar to the ANIvulnerability. This is meant to help illustrate the perceived benefits ofapplying the concept of exploitation properties to aide in the process ofidentifying regions of code that may deserve additional scrutiny based ontheir perceived exploitability.3.1) BackgroundWhile the ANI vulnerability was certainly unique, it was not the first timethe animated cursor code was found to have a security issue. Microsoft patchedan issue that was almost exactly the same as MS07-017 with MS05-002 roughlytwo years prior. In both cases, the underlying security issue was related toa failure to properly validate input that was derived from the contents of ananimated cursor file. Alexander Sotirov provided much of the initial researchon the ANI vulnerability and also gave an excellent write-up to its effect[22].This paper will only attempt to highlight the flaw.The vulnerability itself was found in user32!LoadAniIcon which is responsiblefor processing a number of different chunks that may be contained within ananimated cursor file. Each chunk is a TLV (Type-Length-Value) as describedby the following structure:struct ANIChunk{ char tag[4]; // ASCII tag DWORD size; // length of data in bytes char data[size]; // variable sized data}Keeping this structure in mind, the flaw itself can be seen in the abbreviatedpseudo-code below as modified slightly from Sotirov's original write-up:01: int LoadAniIcon(struct MappedFile* file, ...) {02: struct ANIChunk chunk;03: struct ANIHeader header; // 36 byte structure04: while (1) {05: // read the first 8 bytes of the chunk06: ReadTag(file, &chunk);07: switch (chunk.tag) {08: case 'anih':09: // read chunk.size bytes into header10: ReadChunk(file, &chunk, &header);On line 6, the chunk header is read into the local variable chunk usingReadTag which populates the chunk's tag and size fields. If the chunk's tagis equal to 'anih', the data associated with the chunk is read into the headerlocal variable using ReadChunk on line 10. The problem is that ReadChunk usesthe size field of the chunk as the amount of data to read from the file.Since header is a fixed-size (36 byte) data structure and the chunk's size canbe variable, a trivial stack-based buffer overflow may occur if more than 36bytes are specified as the chunk size. In terms of the vulnerability, that'sall there is to it, but the implications from an exploitation perspective arewhere things start to get interesting.When attempting to exploit this vulnerability it may at first appear that allattempts to do so would be futile. Given Vista's security push, an attackerwould be justified in thinking that surely the LoadAniIcon function isprotected by a GS cookie. This point is especially justified considering themajority of all binaries shipped with Windows Vista have been compiled with GSenabled[27]. However, there are indeed circumstances where the compiler willchoose to not enable GS for a specific function. As chance would have it, thecompiler chose not to enable GS for the LoadAniIcon function because of thesimple fact that it does not contain any characteristics that would suggestthat a stack-based buffer overflow might be possible (such as the use ofstack-allocated arrays). This means that an attacker is able to make use ofexploitation techniques that are associated with traditional stack-basedbuffer overflows. While this drastically increases the chances of being ableto produce a reliable exploit, there are still other mitigations that are ofpotential concern.Another mitigation that might be concerning in most circumstances ishardware-enforced DEP (NX). This would generally prevent an attacker frombeing able to run arbitrary code within regions that are not marked asexecutable (such as the stack and the heap). However, as fate would have it,Internet Explorer is configured to not run with DEP enabled. This immediatelyremoves this concern from the equation for exploits that attempt to triggerthe ANI vulnerability through Internet Explorer. With DEP out of the picture,ASLR becomes a weakened but still potentially significant hurdle. While it may appear that ASLR would be challenging to defeat in mostcircumstances, this particular vulnerability provides an example of twodifferent ways in which ASLR can be bypassed. The simplest approach, as takenby Sotirov, involves making use of the fact that Internet Explorer is notcompiled with support for ASLR and therefore can be found at a fixed addresswithin the address space. This allows an attacker to make use of opcodescontained within iexplore.exe's memory mapping. A second approach, as takenby the author, involves using a partial overwrite to ignore the effects ofASLR completely. The details relating to how a partial overwrite works wereexplained in 2.4.2. In either case, an attacker is able to reliably defeat Vista'sASLR.To compound the problem, the particulars of the context in which thisvulnerability occur make it easier to exploit even without the presence ofmitigations. This improved reliability comes from the fact that theLoadAniIcon function is wrapped in an exception handling context that simplyswallows exceptions that are encountered. This makes it possible for anexploit to fail without actually crashing the process, thus allowing theattacker to try multiple times without having to worry about making a mistakethat crashes the process. When all is said and done, the simplicity of thevulnerability and the ease with which mitigations could be bypassed are whatlead to the ANI vulnerability being quite unique. Given the fact that thisvulnerability can be so easily exploited, it is prudent to describe how itcould have been detected as being a high risk function.3.2) DetectionThe ease of exploitability associated with the ANI vulnerability makes it anobvious candidate for study with respect to the exploitation properties thathave been described in this paper. It should be possible to use extremelysimple criteria to accomplish two things. First, the criteria must identifythe LoadAniIcon function. Second, the criteria should be unique enough tolimit the size of the narrowed subset. Reducing the subset size is beneficialas it may permit the use of more complex program analysis tools which canfurther constrain or explicitly identify instances of vulnerabilities.Determining the specific criteria that is needed to identify the LoadAniIconfunction can help illustrate how one can make use of exploitation properties.Given the description of the ANI vulnerability, one can easily deduce some ofthe more interesting properties that it has.An exploitation property that one might immediately observe is that theLoadAniIcon function does not make use of GS (2.4.1). This makes it possible todefine criteria which states that only functions that have not been compiledwith GS should be considered. Functions that have been compiled with GS areinherently less interesting for the purpose of this exercise due to the factthat they are less likely to contain exploitable vulnerabilities.A second property that the ANI vulnerability had with regard to exploitationwas that it was possible for an attacker to make use of a partial overwrite todefeat ASLR. The exploitation property described in 2.4.2 illustrates how one canmake this determination statically. In the case of the ANI vulnerability, apartial overwrite can be performed by making use of a jmp [ebx] that islocated within the same 16-page aligned region as the caller of LoadAniIcon.Thus, any functions that could potentially make use of a partial overwrite canbe used as additional criteria.At this point, a subset can be produced that is constrained to the regions ofcode that are annotated with the GS and partial overwrite exploitationproperties. It is possible to further refine the set of functions that shouldultimately be considered by studying the form that the ANI vulnerability took.The first point to note is that the stack-based buffer overflow occurred whenwriting beyond the bounds of a struct that was allocated on the stack.Furthermore, the overflow did not actually occur in the immediate context ofthe LoadAniIcon itself. Instead, the overflow was triggered by passing apointer to the stack-allocated struct as a parameter when calling the functionReadChunk.Based on these data points it is possible to define a third criteria. In thiscase, the third criteria is not an exploitation property but is instead anexample of a vulnerability property. While not discussed in detail in thispaper, many examples of vulnerability properties exist, though perhaps notcategorized as such. A vulnerability property can be thought of as anannotation that illustrates whether or not a region of code has a form that issimilar to that seen in vulnerabilities or has the potential of being avulnerability. The complexity of a vulnerability property, as with thecomplexity of an exploitation property, can range from highly sophisticated tovery simplistic.For the purpose of this paper, a vulnerability property can be used that isvery simple and imprecise but nevertheless effective at further narrowing theset of functions that should be reviewed. This property is based on whetheror not a function passes a pointer to a stack-allocated variable as aparameter to a child function. This property is directly derived from thegeneral form that the ANI vulnerability takes. At a minimum, a region of codethat matches this form suggests that a vulnerability could be present.Using these three properties, it should be possible to easily identify boththe function that contains the ANI vulnerability as well as other functionsthat could contain similar vulnerabilities. However, it is important to notethat this process does not produce functions that definitely havevulnerabilities. This can be plainly seen by the fact that both thevulnerable and fixed versions of the LoadAniIcon should be detected by thecriteria described above. While this may seem to run counter to the purposesof this paper, it is important for the reader to remember that the goal ofusing these exploitation properties is not to identify specific instances ofvulnerabilities. Instead, the goal is to identify regions of code that mightwarrant additional scrutiny due to the relative ease with which avulnerability could be exploited if one is found to be present.3.3) Test CaseThe author developed an analysis tool as an extension to Microsoft's Phoenixframework in order to test the ideas described in this paper[12]. Unfortunately,the current release (July 2007 SDK) of Phoenix requires private symbolinformation for native binaries. This limitation prevented the author frombeing able to run the analysis tool across the vulnerable version ofuser32.dll. In lieu of this ability, the author chose to generate a binarycontaining test cases that closely mirror the form of the function containingthe ANI vulnerability.Using these test cases, the author used the features provided by the analysistool to determine the exploitation and vulnerability properties described inthe previous section and to identify the resulting subset of functions meetingall criteria. This was accomplished by first attempting to identify thesubset of functions that do not contain GS within the scope of the targetbinary. After identifying the subset of functions without GS, a second subsetwas taken which consists of the functions that pass a pointer to astack-allocated local variable as a parameter to a child routine. This wasaccomplished by using Phoenix's static single assignment (SSA) and aliasimplementations to collect the requisite data flow information[12,25]. Using thisdata flow information, it is possible to perform backwards data flow analysisto determine the potential storage location of the parameter being passed ateach point along a given data flow path starting from the operand associatedwith a parameter at a call site. The analysis terminates either when a fixedpoint is reached or when it is determined that a pointer to a stack-allocatedvariable could be passed as the parameter.While the previous section described the potential for using the partialoverwrite exploitation property to detect the function containing the ANIvulnerability[6], it is not possible to create a meaningful parallel between thetest binary and that of the ANI vulnerability. This is due in part to thefact that while it would certainly be possible to artificially place a usefulopcode at a specific location in the test binary, it would not add any valuebeyond showing that it is possible to detect useful opcodes within the same16-page aligned region as the caller of a given function. The author feelsthat this point is somewhat moot given the fact that it has already beenproven that a partial overwrite can be used with the ANI vulnerability. Theonly additional benefit that it could offer in this case would be to helpfurther constrain the resultant set size. However, without being able to runthis analysis against the vulnerable version of user32.dll, it is not possibleto draw meaningful conclusions at this point in time.3.4) ResultsThe results of running the analysis tool against the test binary produced theexpected behavior. To illustrate this, it is helpful to consider a samplingof the functions that were analyzed. The following functions have a form thatis similar to the ANI vulnerability. These functions also match the criteriadescribed in the previous subsection. Specifically, these functions do notmake use of GS and pass a pointer to a stack-allocated local variable (var) toa child function:int tc_df_pass_local_ptr_to_callee() { int var; tc_df_pass_local_ptr_to_callee_func(&var); return 0;}int tc_df_pass_local_ptr_to_callee_alias() { int var; int *p = &var; tc_df_pass_local_ptr_to_callee_func(p); return 0;}int tc_df_pass_local_ptr_to_callee_alias_struct( struct _foo *foo) { int var; foo->ptr = &var; return tc_df_pass_local_ptr_to_callee_func( foo->ptr); return 0;}Additionally, a handful of different test functions were also included in thetarget binary in an effort to ensure that other scenarios were not improperlydetected as matching the criteria. Some examples of these functions include:int tc_df_pass_local_to_callee_alias() { int var = 2; int p = var; tc_df_pass_local_to_callee_func(p); return 0;}int tc_df_pass_local_to_callee_deref() { int var = 2; int *p = &var; tc_df_pass_local_to_callee_func(*p); return 0;}int tc_df_pass_heap_ptr_to_callee(struct _foo *foo) { tc_df_pass_local_ptr_to_callee_func(&foo->val); return 0;}When running the analysis tool against the target binary, the following outputis shown:>PhaseRunner.exe detectani.xml dfa.exeRunning phase: ANI Detection ... 1 target(s)Displaying 3 normalizables at the ProgramElement.Method granularity...00001: dfa!tc_df_pass_local_ptr_to_callee_alias00002: dfa!tc_df_pass_local_ptr_to_callee00003: dfa!tc_df_pass_local_ptr_to_callee_alias_structWhile this unfortunately does not prove that these techniques could be used toidentify the function containing the ANI vulnerability, it does neverthelesshint at the potential for detecting the function containing the ANIvulnerability using its suggested exploitation and vulnerability properties.As an side, another interesting way in which this type of detection can beaccomplished is through the use of Language Integrated Queries (LINQ) whichare now supported in Visual Studio 2008[11]. For instance, a simple LINQexpression for the above narrowing operation can be expressed as:var matches = from Method method in engine.GetScopeMethods() where !method.IsGuardStackEnabled() && method.IsPassingStackLocalPtrToChild() select method;foreach (var method in matches) Console.WriteLine("{0} matches", method);4) Potential UsesProgram analysis is one area that may benefit from the use of exploitationproperties. In particular, an auditor can make use of exploitation propertiesto assist in the process of identifying regions of code that should be auditedmore closely or with greater precedence. This determination can be made byusing exploitation properties to understand the ease of exploitationassociated with specific binaries or functions. By combining this informationwith other data that is collected either manually or automatically, an auditorcan get a better understanding of the security aspects that are associatedwith a system. This is beneficial both to an attacker and a defender. Anattacker can identify regions of code that would be easier to exploit and thusdevote more time to auditing those regions. Likewise, a defender can use thisinformation to the same extent but for different purposes. This type ofinformation is especially useful to a defender who needs to balance the costassociated with performing security reviews because it should offer a betterunderstanding of what the business cost might be if a vulnerability is foundin a region of code. This cost can be derived from the negative publicity andresponse effort needed to cope with a flaw that is found publicly in a regionof code that is widely exploited. For example, consider some of the Windowsflaws that have lead to wormable issues and the cost they have had relative toother issues.Exploitation properties may also benefit the security community by helping toidentify ways in which future mitigations can be applied. This would involveanalyzing regions of code that could be more easily exploited in an effort todetermine what other forms of mitigations could help to protect these regions,if any. This information could be fed back to the compiler to make itpossible for mitigations to be enabled that might otherwise be disabled bydefault. For example, a function that by default would not have GS but issubsequently found to be highly exploitable may benefit from having thecompiler insert GS.5) Future WorkWhile this paper has defined exploitation properties and described a handfulof concrete examples, it has not attempted to formally define the correlationbetween exploitation properties and the exploitation techniques they areassociated with. Future research will attempt to concretely define thisrelationship as it should lead to a better understanding of the variables thatpermit the use of various exploitation techniques. Using more formaldefinitions of exploitation properties, a larger scale case study can becompleted which collects data about the effect of using exploitationproperties to improve program understanding for a variety of purposes. Theauthor views exploitation properties as being one component in a larger model.This larger model could be used to join major areas of study within computersecurity including attack surface analysis, vulnerability analysis, andexploitation analysis to form a more complete understanding of the true risksassociated with a system.6) ConclusionThis paper has introduced the general concept of exploitation properties anddescribed how they can be used to better understand the exploitability of asystem. The purpose of an exploitation property is to help convey the easewith which a vulnerability might be exploited if one is found to be present.Exploitation properties can be broken down into different categories based onthe configuration or context that a given property is associated from. Thesecategories include operating platforms, running processes, binary modules, andfunctions.Exploitation properties can be used to provide an alternative understanding ofan application's attack surface from the perspective of which areas would bemost trivially exploited. This can allow an attacker to focus on findingsecurity issues in code that would be more easily exploited. Likewise, adefender can draw the same conclusions and direct resources of their own atreviewing the associated code. It may also be possible to use thisinformation to augment existing mitigations or to come up with newmitigations. A contrived example based on the form of the ANI vulnerabilitywas used to illustrate an automated approach to extracting exploitationproperties and using them to help identify a constrained subset of regions ofcode that meet a specific criteria. Future research will attempt to betterdefine the extent of exploitation properties and their uses. [1] Dowd, M., Metha, N., McDonald, J. Breaking C++ Applications. https://www.blackhat.com/presentations/bh-usa-07/Dowd_McDonald_and_Mehta/Whitepaper/bh-usa-07-dowd_mcdonald_and_mehta.pdf[2] Durden, Tyler. Bypassing PaX ASLR Protection. July, 2002. http://www.phrack.org/issues.html?issue=59&id=9[3] Howard, Michael. Protecting against Pointer Subterfuge (Kinda!). http://blogs.msdn.com/michael_howard/archive/2006/01/30/520200.aspx[4] Johnson, Richard. Windows Vista: Exploitation Countermeasures. http://rjohnson.uninformed.org/[5] Litchfield, David. Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server. http://www.nextgenss.com/papers/defeating-w2k3-stack-protection.pdf[6] Metasploit. Exploiting the ANI vulnerability on Vista. http://blog.metasploit.com/2007/04/exploiting-ani-vulnerability-on-vista.html[7] Microsoft Corporation. Microsoft Security Bulletin MS05-002. Jan, 2005. http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx[8] Microsoft Corporation. /GS (Buffer Security Check). http://msdn2.microsoft.com/en-us/library/8dbf701c(VS.80).aspx[9] Microsoft Corporation. /SAFESEH (Image has Safe Exception Handlers). http://msdn2.microsoft.com/en-us/library/9a89h429.aspx[10] Microsoft Corporation. A detailed description of the Data Execution Prevention (DEP) feature. http://support.microsoft.com/kb/875352[11] Microsoft Corporation. The LINQ Project. http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx[12] Microsoft Corporation. Phoenix. http://research.microsoft.com/phoenix/[13] Microsoft Corporation. Microsoft Portable Executable and Object File Format Specification. http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.doc[14] Microsoft Corporation. Threat Modeling. June, 2003. http://msdn2.microsoft.com/en-us/library/aa302419.aspx[15] PaX Team. ASLR. http://pax.grsecurity.net/docs/aslr.txt[16] Ren, Chris et al. Microsoft Compiler Flaw Technical Note. http://www.cigital.com/news/index.php?pg=art&artid=70[17] Rahbar, Ali. An analysis of Microsoft Windows Vista's ASLR. Oct, 2006. http://www.sysdream.com/articles/Analysis-of-Microsoft-Windows-Vista's-ASLR.pdf[18] skape, Skywing. Bypassing Windows Hardware-enforced DEP. http://www.uninformed.org/?v=2&a=4&t=sumry[19] skape. Preventing the Exploitation of SEH Overwrites. http://www.uninformed.org/?v=5&a=2&t=sumry[20] skape. Reducing the Effective Entropy of GS Cookies. http://www.uninformed.org/?v=7&a=2&t=sumry[21] Skywing. Vista ASLR is not on by default for image base addresses. http://www.nynaeve.net/?p=100[22] Sotirov, Alexander. Windows Animated Cursor Stack Overflow Vulnerability. March, 2007. http://www.determina.com/security.research/vulnerabilities/ani-header.html[23] Wikipedia. Stack-smashing protection. http://en.wikipedia.org/wiki/Stack-smashing_protection[24] Wikipedia. Address space layout randomization. http://en.wikipedia.org/wiki/ASLR[25] Wikipedia. Static single assignment form. http://en.wikipedia.org/wiki/Static_single_assignment_form[26] University of Wisconsin. Wisconsin Program-Slicing Project's Home Page. http://www.cs.wisc.edu/wpis/html/[27] Whitehouse, Ollie. Analysis of GS protections in Microsoft Windows Vista. http://www.symantec.com/avcenter/reference/GS_Protections_in_Vista.pdf
