Internet Explorer offers layered defenses to protect against and mitigate each of three major classes of threats that browser users face when surfing the sometimes-hostile Web:
- Technological attacks designed to exploit the browser or operating system
- Web attacks designed to exploit vulnerabilities in Web sites
- Social engineering attacks against the user’s trust
Today’s post covers how browsers’ memory protections mitigate threats in the first class.
Preventing Reliable Exploitation
The goal of these memory protection features is helping prevent reliable exploitation of a memory-related vulnerability. Each technology in the “alphabet soup” of acronyms below is a way to securely terminate the browser tab before malicious code can run. Internet Explorer 9 utilizes the latest memory protection technologies to help prevent an attacker’s code from running if a memory-related vulnerability is discovered in the browser or one of its add-ons:
DEP/NX (Data Execution Prevention / No eXecute) is enabled by default in Internet Explorer 8 and 9 and it is the foundation of memory protection in the browser. DEP/NX works with your system’s processor to distinguish between code and data, helping to prevent execution of data placed into memory by an attacker. If the processor determines that it has been directed to execute a block of memory lacking the proper marking, it will securely terminate the process before executing the specified instructions.
ASLR (Address Space Layout Randomization) is a defense that helps ensure that the memory space of a process is laid out in an unpredictable manner. ASLR helps ensure that an attacker cannot easily bypass DEP/NX protections using a trick called “Return Oriented Programming” in which the attacker simply sets up the attack and jumps to existing code locations, abusing functions which are a part of the browser and operating system. For instance, a common trick is to attempt to jump to the VirtualProtect function which allows memory to be marked as “code” rather than data—if successful, this effectively bypasses DEP/NX. By ensuring that VirtualProtect and other functions are at unpredictable locations, exploit code will generally crash with an Access Violation instead of running successfully.
In IE9, we’ve improved our memory layout randomization to help eliminate predictable memory mappings. However, ASLR is enabled on a per-DLL basis, and some older browser add-ons are not properly opted in to the mitigation. You can use the Process Explorer tool from SysInternals to examine the loaded DLLs in a process to determine whether DEP/NX protection is successfully applied to each. For instance, in the following screenshot, you’ll see that all of the DLLs loaded by the Internet Explorer tab process have ASLR enabled except one ActiveX control which is missing the protection. If that DLL exposes any code segments useful to an attacker, the lack of ASLR randomization could provide a toehold into bypassing memory protections.
Note: Enthusiasts can force ASLR to be applied to all DLLs in the process using EMET (Enhanced Mitigation Experience Toolkit), a security tool provided by the Microsoft Security Research and Defense team to prototype cutting-edge security mitigations. Forcing ASLR onto DLLs which are not expecting it may introduce compatibility problems, however, so keep that in mind if you try out this tool.
SafeSEH (Safe Structured Exception Handling) is a compiler option which helps prevent the injection of malicious structured exception handlers into an exception handling chain. All 64bit code and all of Internet Explorer’s code is compiled with the SafeSEH flag. However, like ASLR, this mitigation is enabled on a per-DLL basis, and hence it requires that add-ons be compiled with the flag in order to ensure comprehensive protection.
This limitation of SafeSEH is mitigated in Internet Explorer 9 when running on Windows 7. IE9 opts-in to SEHOP (Structured Exception Handler Overwrite Protection) a new feature which is enabled on a per-process basis and hence does not require opt-in by individual DLLs. SEHOP works by validating the integrity of the exception handling chain before dispatching exceptions. This helps ensure that structured exception handling cannot be used as an exploit vector, even when running outdated browser add-ons that have not been recompiled to take advantage of SafeSEH.
Lastly, Internet Explorer 9 is compiled with the new C++ compiler provided with Visual Studio 2010. This compiler includes a feature known as Enhanced GS aka Stack Buffer Overrun Detection, which helps prevent stack buffer overruns by detecting stack corruption and avoiding execution if such corruption is encountered. In the latest compiler, the existing GS feature was enhanced to block a broader range of attacks, and it utilizes better heuristics to determine which functions need protection. This enhancement helps minimize the performance impact and maximize protection for Internet Explorer.
Learn More
Software developers can learn more about Internet Explorer’s defenses, including how to use these techniques to improve the security of their own products, by reading the Windows ISV Software Security Defenses whitepaper on MSDN.
Thanks for your help securing the Web.
—Eric Lawrence, Senior Program Manager, Internet Explorer