Using the Enhanced Mitigation Experience Toolkit to Safeguard Against Zero DaysPublished: December 16, 2010 Authors: Fermin J. Serna, Security Software Engineer - MSRC, and Andrew Roths, Senior Security Development Lead - MSRC There have been a number of zero-day vulnerabilities circulating around the Internet recently. A zero-day vulnerability is a security issue in a product that is disclosed publicly before the vendor has created a security update for it. In a zero-day exploit, the program takes advantage of the product vulnerability in order to compromise a machine by running attacker-controlled code. Zero-day exploits are a significant concern because in many cases there are no workarounds with which to block the exploit, and, therefore, no way for users to protect themselves. Some examples of zero-day vulnerabilities include the Adobe Acrobat Reader SING overflow, a couple Adobe Flash vulnerabilities involving malformed code in the ActionScript language, the QuickTime “Marshalled_pUnk” vulnerability, and many others. Zero-day vulnerabilities can happen to any vendor; therefore, zero-day exploitation can also happen to anyone. One of the solutions Microsoft is offering to minimize the risks of zero-day exploitation is the Enhanced Mitigation Experience Toolkit (EMET). EMET provides new layers of security by implementing extra security mitigations. Briefly described, a security mitigation is a technology that makes the successful exploitation of a vulnerability more difficult and less reliable. Take a look at Michael Howard’s article “Protecting Your Code with Visual C++ Defenses” for a brief overview of some of these technologies. EMET allows users to manage the security mitigations on their system and provides several advantages:
Now, let’s dive into one of the unique EMET mitigations, Mandatory Address Space Layout Randomization (ASLR), to see how it works and how it helps prevent successful exploitation. Mandatory ASLR builds on the ASLR mitigation that has shipped with every version of the Windows operating system since Windows Vista. ASLR works by randomizing the addresses where executables and modules are loaded, which helps prevent an attacker from leveraging data at predictable locations. Because an attacker must guess where the data they need is located, a successful attack is less likely. There is a problem, though. Even when an application has opted in to ASLR, some of the dynamic-link library (DLL) files being used by the application can be placed at predictable locations. This happens when DLLs are not compiled with the /DYNAMICBASE linker option. However, when mandatory ASLR is enabled, EMET solves this problem by forcing the relocation of the DLLs. To see how Mandatory ASLR can help block exploitation, let’s take a look at the metasploit module for the Adobe SING stack overflow vulnerability. This exploit relies on several return-oriented programming (ROP) gadgets located on a non-ASLR-aware module, icucnv36.dll. ROP gadgets are pieces of code used by attackers to bypass Data Execution Prevention (DEP). Attackers commonly use gadgets from predictable mappings, thus circumventing ASLR. The first ROP gadget used places the stack at a controlled place. This can be done because the attacker can reuse these lines of assembly from the non-ASLR module. Here is what the ROP gadget looks like: 0:000> u 0x4a80cb38 L3 When EMET is in place and Mandatory ASLR is enabled, this DLL will be relocated to a random place. The exploit will try to jump to 0x4a80cb38 but, since the DLL was relocated, an attempt to change the ESP stack register to a controlled place will fail. Here, you can see the ROP gadget is not present: 0:001> u 0x4a80cb38 L3 This mitigation has proved to be quite effective, and even the author of the metasploit module for this vulnerability suggests installing EMET so it will be harder to successfully exploit the vulnerability. Mandatory ASLR it just one of the six mitigations bundled with EMET version 2.0. To read more about EMET, including a link to the User’s Guide, please refer to this blog post. As a final note, we would like to point out that while EMET will minimize the risks of exploitation, it is by no means 100-percent effective and should not be considered an alternative for security updates and patching. Instead, EMET should be used in conjunction with other efforts to safeguard your environment. | About the Authors
Related ResourcesMicrosoft Security NewsletterSign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers. |
.jpg "Fermin Serna")
Fermin J. Serna s a Security Software Engineer in the MSRC Engineering team. Prior to joining Microsoft, he spent 7 years in Spain working as a Penetration tester and lately running his own company in the security field. He has collaborated with US-CERT in the responsible disclosure of several vulnerabilities, such as CA-2002-12 for ISC-DHCP, and published documents on exploitation techniques on rare architectures such as SPARC and PA-RISC..jpg "Andrew Roths")
Andrew Roths manages one of two MSRC Engineering teams. His team is responsible for triaging externally discovered security issues and helping to ensure they are addressed appropriately. Other responsibilities of his team include hunting for variations of security issues and providing technical guidance to customers. Prior to being a manager, Andrew was part of Microsoft's Security Engineering Center (MSEC). .png)
