*** UPDATE: Version 2.0 of EMET is now available. Click here to read more about it. ***
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.
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:
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.
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.
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
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:
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.
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.
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.
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.
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.
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.
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.
We’ve put together a Bluehat video to walk through the tool and explain many of its advantages and capabilities. The video can be found on the BlueHat site linked here. We hope you enjoy it.
Thanks to Matt Miller and Ken Johnson for their work on EMET.
- Andrew Roths and Fermin J. Serna, MSRC Engineering