*** UPDATE: Version 2.0 of EMET is now available. Click here to read more about it. ***
What is EMET?
In October 2009, we released a tool on this blog called EMET that provides users with the ability to deploy security mitigation technologies to arbitrary applications. Doing so helps to prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited. It also responds to requests from customers to help manage risk in older, legacy products while they are in the process of transitioning over to modern, more secure products. Beyond that it makes it easy for customers to try mitigations against any software and provide feedback on their experience to the vendor.
What is new with version 2?
EMET sparked customer interest and based on the feedback that we received, we decided to release version 2 that includes more mitigations, a better interface, and a more robust infrastructure compared to the earlier version of EMET.
Our aim with this version is to provide an innovative solution that helps customers manage risk and minimize disruption in their environment. This is reflected in our goals for the release:
Leverage the tool for vulnerabilities under active exploitation to help customers prevent themselves from being exploited.
Give customers the ability to use newer mitigation technologies to help protect older applications that cannot be recompiled to opt into them.
Provide a central interface to make it easier for users to manage both system and application mitigations.
These new goals increase the scope of EMET significantly from version 1. As a result, the old definition of EMET (Enhanced Mitigation Evaluation Toolkit) is no longer a good fit. With version 2, we are changing the EMET acronym to stand for Enhanced Mitigation Experience Toolkit to reflect this.
How can I benefit from it?
While EMET can be used by anybody, it is primarily targeted at protecting applications on machines that are at high risk for attack. Good examples include line of business applications on backend servers and browsers on the desktops of corporate executives. These are scenarios where an application compromise could be particularly damaging.
As with most software, deploying this tool will likely involve an individual, such as an IT professional, testing to ensure that EMET works smoothly with applications where the mitigations are desired (like line of business applications and 3rd party products). Once in place, EMET will be transparent to the end user.
That said of course EMET is also ideal for any security savvy user wishing to harden the apps they use against possible exploitation. Developers and security professionals can also use it as a convenient way to try out security mitigations.
Can you give an example where mitigations have helped in the past?
During the Aurora outbreak back in January 2010, Data Execution Prevention and Address Space Layout Randomization (two types of mitigation technologies) played an important in blocking known attacks. You can find more information on these SRD blog posts IE Vulnerability Risk Accessment and DEP and the New IE Vulnerability
What mitigations will be supported in version 2?
The new version of EMET will include a total of six mitigations. Four of them are from the original EMET, while Export Address Table Access Filtering and Mandatory Address Space Layout Randomization are new for version 2. Here are some more details on the mitigations:
Dynamic Data Execution Prevention (DEP)
DEP has been available since Windows XP. However, current configuration options don’t allow applications to be opted in on an individual basis unless they are compiled with a special flag. EMET allows applications compiled without that flag to also be opted. For more information on what DEP is and how it works, take a look at Part 1 and Part 2 of our two-part SRD blog post on it.
Structure Exception Handler Overwrite Protection (SEHOP)
This protects against currently the most common technique for exploiting stack overflows in Windows. This mitigation has shipped with Windows since Windows Vista SP1. Recently with Windows 7, the ability to turn it on and off per process was added. With EMET, we provide the Windows 7 capabilities on any platform back though Windows XP. For more information, take a look at the SEHOP Overview and Window 7 SEHOP Changes blog posts.
Heap Spray Allocation
When an exploit runs, it often cannot be sure of the address where its shellcode resides and must make a case when taking control of the instruction pointer. To increase the odds of success, most exploits now use heapspray techniques to place copies of their shellcode at as many memory locations as possible. This mitigation blocks the use of addresses most common in today’s exploits.
Null Page Allocation
This is similar technology to the heap spray allocation, but designed to prevent potential null dereference issues in usermode. Currently there are no known ways to exploit them and thus this is a defense in depth mitigation technology.
Export Address Table Access Filtering
This mitigation is designed to break nearly all shell code in use today. Before a piece of shellcode can do anything useful, it generally has to locate windows APIs first. This mitigation blocks a common current technique shellcode uses to do this.
Mandatory Address Space Layout Randomization (ASLR)
ASLR randomizes the addresses where modules are loaded to help prevent an attacker from leveraging data at predictable locations. The problem with this is that all modules have to use a compile time flag to opt into this. With EMET, we force modules to be loaded at randomized addresses for a target process regardless of the flags it was compiled with.
Where can I download it?
Please stay tuned for the actual binaries which will get released in the upcoming weeks. Our blog will be updated with the latest news and download links as soon as that happens.
Where can I get more info on EMET v2?
Thanks to Matt Miller and Ken Johnson for their work on EMET.
– Andrew Roths and Fermin J. Serna, MSRC Engineering