At the recent Pwn2Own contest held during the CanSecWest 2010 security conference, the Web browser targets were the latest versions of Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, and Apple Safari. All of the targeted browser platforms were patched up to date and included the latest anti-exploitation technologies. In spite of this, Peter Vreugdenhil succeeded in leveraging two vulnerabilities in Internet Explorer 8 on Windows 7 64-bit to execute and reliably run arbitrary code, bypassing Microsoft’s latest security defenses. Internet Explorer 8 was not the only browser to fall—Charlie Miller exploited the Safari browser on OSX, and Nils exploited Mozilla Firefox on Windows 7.
So, why do Web browsers make such good targets for exploit developers? First off, the Web browser handles untrusted and therefore unpredictable data, and this data often passes through several security boundaries before the processing of the data is complete. The Web browser is a large application, even before considering all of the browser extensions and plug-ins that are often reachable from the Web. All of this functionality allows a remote attacker to maintain a great deal of control over the application through supplied code and content; this level of control is unparalleled in most other client software. As such, it allows the exploit developer to have a fine degree of control over application memory state. For memory corruption vulnerabilities, controlling memory layout can be of critical importance to exploit developers.
In the case of Internet Explorer, the exploit developer can employ browser add-ons such as ActiveX, Flash, JavaScript, VBScript, .Net, and Java, as well as native browser functionality to aid in the process of massaging memory and seizing control of the application. To hinder exploit developers, Microsoft has added anti-exploitation technologies such as Address Space Layout Randomization (ASLR), data execution prevention (DEP), GuardStack (GS) stack cookies, safe-structured exception handling (SafeSEH), and structured exception handler overwrite protection (SEHOP) to modern versions of Windows operating systems. In the case of process memory corruption vulnerabilities, even when a vulnerability allows an exploit developer to bypass GS, SafeSEH, or SEHOP, they are still faced with the problem of executing their code. DEP attempts to prevent code execution by marking regions of memory that store data non-executable. Further details about DEP on Microsoft Windows is described in “A detailed description of the Data Execution Prevention (DEP) feature.”
Security researchers responded to the adoption of DEP by using special types of shellcode programming techniques called “return into libc” and “return-oriented programming.” Essentially, the former involves populating memory with arguments and function addresses in such a way that the vulnerable program calls existing library functions that are marked executable. The second technique involves reusing application code-chunks that are also marked executable—this technique is described in Return-oriented Programming without Returns (on the x86) [PDF]. An example of an application of these types of techniques on Microsoft Windows is described in Bypassing Windows Hardware-enforced Data Execution Prevention. The exploit developer can use both of the aforementioned shellcode methods to disable DEP. DEP is defeated in the above attack method; however, to use either of these techniques, an exploit developer must be able to predict the addresses of reusable code in the target application or loaded libraries. Failing to correctly predict the location of code will cause the exploit to fail, likely causing the application to crash.
ASLR was introduced to hinder “return into libc” and “return-oriented programming” programming techniques. ASLR attempts to prevent program code from being mapped to predictable locations, which decreases the odds that the exploit developer will successfully guess the address of reusable code relative to the application. The idea is that the exploit reliability decreases to such a level that exploitation attempts are impractical. As such, many administrators place trust in the combination of DEP and ASLR technologies. However—as was seen in this recent Pwn2Own contest—in a Web browser the exploit developer has a huge set of tools at their disposal to reduce the effectiveness of ASLR and DEP.
As a result, it is the author’s opinion that ASLR and DEP can lead to a false sense of security. It is important to remember there is currently no perfect solution to the problem of defeating exploitation; all security-aware professionals should know that some technologies might break down in light of new techniques. Recently, there has been some novel research into effective techniques that can be used to bypass ASLR and DEP completely. At Blackhat DC 2010, Dion Blazakis presented several methods that employ Adobe Flash to disclose memory address information (called pointer inference), as well as techniques that could be used to bypass DEP (using JIT Spraying – INTERPRETER EXPLOITATION: POINTER INFERENCE AND JIT SPRAYING). Currently, these attack strategies essentially act to render ASLR and DEP useless for some browser vulnerabilities when a browser plug-in that provides the required functionality is present.
At Pwn2Own, Peter Vreugdenhil exploited two issues in Internet Explorer to gain control of the process. The first issue was leveraged to overwrite a null terminator for a UTF8 string so that it was no longer terminated. This results in a condition in which a request for this string reads until the next null terminator sequence is encountered. Peter was able to use this to leak process memory that was adjacent to this string—process memory that contained a vftable address that could be used to derive the base address of the DLL that the object belongs to. Once the base address is acquired, ASLR has been bypassed and it is possible to write a return-oriented programming style shellcode to also disable DEP. From here, code-execution is more straightforward. (This is a gross oversimplification of the process, apologies to Peter. Further information on his exploit can be found in the details he released in the PDF Pwn2Own 2010 Windows 7 Internet Explorer 8 exploit.)
So, what is my point? ASLR and DEP are important anti-exploitation advancements and in some cases they assist in hindering memory corruption vulnerability exploitation. However, it is important that we do not consider these technologies a panacea for such vulnerabilities. The effectiveness of ASLR and DEP in protecting against reliable exploitation of a vulnerability is heavily influenced by the attack surface of the targeted application and the persistence and capability of the exploit developer.