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.
Read more: IE Blog
Posts
0 comments:
Post a Comment