Skip to main content


Using the Enhanced Mitigation Experience Toolkit to Safeguard Against Zero Days

Published: 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:

  • Highly configurable: With EMET, mitigations can be individually enabled and disabled on a per-process basis. There is no need to recompile a process or change system policies for all processes. Users can simply select which mitigations get applied to which processes. This also allows users to apply mitigations to software that was compiled before the mitigations were even available.
  • The latest mitigations: EMET comes bundled with many of the latest mitigation technologies, several of which are unique to EMET and not available elsewhere. These cutting edge technologies help provide users with the most up-to-date protection.
  • Ongoing improvement: The release cycle for EMET is not tied to any product. EMET updates can be made dynamically as soon as new mitigation technologies become available. The platform is designed so that the mitigations can be updated as attackers start trying to evade them.
  • Supports OS policies: The policy for OS-supported mitigations can be seen and configured with EMET's graphical user interface. There is no need to locate and decipher registry keys or run platform-dependent utilities. Your mitigations can be seen and configured from a central point.

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
4a80cb38 81c594070000 add ebp,794h
4a80cb3e c9 leave
4a80cb3f c3 ret

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
4a80cb38 ?? ???
^ Memory access error in '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

Fermin Serna photoFermin 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.

Andrew Roths photoAndrew 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).

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.