Windows Enhanced Mitigation Experience Toolkit (EMET) is a Windows add-on that improves the defensive posture of...
the system it is installed on by adding operating system-based attack mitigations to applications that may be vulnerable to known or unknown vulnerabilities.
EMET version 2 (from here on, simply EMET) improves on the mitigations available in the original October 2009 release (EMET version 1). EMET supports six mitigation techniques that prevent common attack techniques, primarily related to stack overflows and the techniques used to by malware to interact with the operating system as it attempts the compromise. EMET does not remove or repair the vulnerability per-se, but reduces the risk of a vulnerability being exploited to any effect. Furthermore, EMET is designed as a modular platform so additional security mitigations can be added in the future. In short, for those of you who don't like details, EMET:
- Improves the resiliency of Windows to the exploitation of buffer overflows.
- Allows Windows to harden applications that have not been compiled (by the original vendor) with specific security countermeasures.
Some EMET mitigations apply to the core OS and others are applied on an application-by-application basis. EMET is most helpful for hardening an application that may be vulnerable (perhaps a legacy application). For those users who have asked about securing Internet Explorer 6 or Adobe Reader, Microsoft's security blog has a very informative article about the use of EMET to protect Adobe Acrobat and Adobe Reader from zero-day attacks.
Before talking about EMET features in more depth, I need to review stack overflows. Although this is a common term, not many people understand what is actually happening. That knowledge, at least at a high level, is important for understanding some of EMETs features. Generically speaking, a stack overflow is a logic error that allows an attacker to interfere with the execution stack of an application and, possibly, inject malicious instructions into that execution stack. To be exploitable, the attacker must:
- Be aware of the stack overflow vulnerability.
- Be able to trigger the overflow condition.
- Get malicious instructions (code) successfully executed by the vulnerable application.
Some stack overflows can be triggered but not reliably used to run the attacker's code -- these usually cause a denial-of-service (DoS) on that vulnerable application or the operating system as a whole. An example of a stack overflow is CVE-2008-2992, an Adobe Reader vulnerability from 2008.
The following table lists the mitigations included in EMET, taken directly from the user's guide, along with a simplified explanation of the feature's purpose:
|Structure Exception Handler Overwrite Protection (SEHOP)||SEHOP enabled Windows to verify the execution stack to verify it is unchanged.|
|Dynamic Data Execution Prevention (DEP)||DEP prevents code in memory from being executed unless it is explicitly flagged as executable.|
|Heapspray Allocations||Common memory locations are pre-allocated by EMET so attacks that attempt to place attack code in those locations will fail. This mitigation implementation is directly based on existing attacks.|
|Null page allocation||Another method to protect memory from being exploited by attackers. Microsoft notes that no known attacks of this nature exist, so this is a more proactive mitigation.|
|Mandatory Address Space Layout Randomization (ASLR)||ASLR randomizes the location of modules and functions so an attacker cannot predict them. EMET forces this feature upon applications that were not compiled to use it, allowing improved hardening of high-risk applications.|
|Export Address Table Access Filtering (EAF)||EAF makes it more difficult to exploit code to find and take advantage of Windows APIs. This will often stop an exploit from successfully compromising the system.|
Data Execution Prevention (DEP) is a good illustrative example of how EMET version 2 can help protect your system; it is a protective feature available as of Windows XP Service Pack 2 that makes stack and buffer overflow attacks more difficult by limiting which portions of memory code can be executed from. To take advantage of this feature, the programs you use must be explicitly compiled by the vendors. EMET makes DEP more effective by allowing you to apply DEP to any executable even if the vendor did not compile the program for DEP. A program protected by DEP is more difficult to exploit. That makes you more secure.
DEP, to deviate slightly, is a security feature you should seriously consider if you are using IE6. Microsoft advisory MS10-002 is an excellent example of an actively exploited critical vulnerability that can be mitigated through the use of DEP -- which provided that protection even before the specific vulnerability was known. EMET does not need to be used to enable DEP for IE 6, but you do need to explicitly enable DEP.
EMET is supported on Windows XP SP 3, Vista SP 1, Windows 7, Windows Server 2003 SP 1 and Server 2008. Please see the EMET user guide for a matrix of which features are available for each OS. To get started with EMET you must install it and then enable the features you want (and are supported by your OS). You can then add EMET protection to each application.
Figure 1 shows the configuration of the OS-level features on a Windows XP SP3 system (only DEP is supported). Figure 2 shows the application-specific features enabled for Adobe Acrobat. Again, each application to be protected must be manually added; there is no "protect everything" button. You should also test these features before deploying them to any critical systems.
Since manually adding each application can be cumbersome when applying this on any scale, you can use command-line instructions to add applications to EMET. If you wanted, for example, to roll out EMET to a number of servers and protect 10 specific executables you could have an installation script locate each executable file and pass the location on to EMET with the "EMET_conf –add" command. Command-line configuration options are discussed in section three of the user guide.
Lastly, the Microsoft Security Research and Defense group, which released EMET, has a blog with security analysis of Microsoft vulnerabilities and attacks on Microsoft products; this blog is very informative and I recommend Windows administrators read it.
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.
Send Tom your security questions.
Join us on LinkedIn.