EMET: a « new » vulnerability prevention tool
Date : October 04, 2010
The goal of this article is to present EMET (Enhanced Mitigation Toolkit Experiment), the vulnerability exploitation prevention tool developed by Microsoft. Publicly distributed for a year already, it has been recently updated on September 2nd in version 2.0. Almost unnoticed despite an announcement on Microsoft security blog, it is only recently, thanks to a security vulnerability in Adobe Reader, that this tool reappears.
Indeed the recent “0-day” exploitation of the CVE-2010-2884 vulnerability in Adobe Reader (see CERT-IST/AV-2010.433), pushed Adobe to recommend the use of EMET in order to contain the exploitation of this vulnerability, waiting the editor to release a patch.
EMET’s goals
The EMET tool is a vulnerability exploitation prevention tool, which acts in a “nonintrusive” manner. It does not require compiling or recompiling the code of applications, neither including specific component or module in the software to be protected, nor executing them in confined environment.
EMET works in depth at the level of system layers in the operating system in order to apply protection techniques such as DEP, ASLR and SEHOP, which were introduced into the latest versions of Windows operating systems. These technologies allow the protection of the software and applications in order to counter attacks commonly driven by malicious programs. In particular, it concerns the majority memory overflows (buffer overflows, heap overflows, integer overflows, etc).
Note: It is important to note that the techniques used by EMET run at a user mode level, it thus cannot prevent attacks at the kernel level (kernel mode).
Protection techniques
The first version of EMET (1.0.2) was distributed by Microsoft on October 27th, 2009. At that time, this version was only integrating 4 protection techniques (protection of the heap, protection of Null pages, DEP and SEHOP). The new version (2.0), distributed since September 2nd, 2010, integrates 2 new protection technologies (ASLR and EATAF).
EMET is compatible with 32bits and 64bits Windows operating systems. It supports the following systems: Windows 7, Windows Server 2003 Service Pack 1, Windows Server 2008, Windows Server 2008 R2, Windows Vista Service Pack 1 and Windows XP Service Pack 3.
Even though EMET is available for free, Microsoft currently does not provide any support regarding the tool.
Note: All technologies are not available on all the operating systems (e.g. SEHOP and ASLR cannot be configured on Windows XP or Windows Server 2003).
#1 - SEHOP (Structure Exception Handler Overwrite Protection) protection
SEHOP allows to protect the SEH (Structured Exception Handler) exception management chain that is part of any executables. This mechanism protects from memory overflow attacks, which consists in overwriting a record of an exception pointer with a controlled value. This technique indeed allows the attacker execute arbitrary code by triggering an exception after having modified an SHE structure.
Note:
- This protection exists on Windows systems since Windows Vista SP1. It is not available under Windows XP.
- The Windows 7 version offers now the ability to enable or disable the SEHOP protection independently on a per application basis.
#2 - Dynamic DEP (Data Execution Prevention)
DEP is a protection mechanism which consists in marking certain memory regions as “non executable”. This mechanism allows for example to prevent the execution of a code which the attacker would have placed in a variable of the program or on the stack.
Note: Cert-IST has published an article regarding this mechanism in the April 2010 bulletin (see « DEP (Data Execution Prevention) »)
#3 - NULL page allocation
This mechanism consists in blocking the exploitation programs using the NULL pointer dereference. It functions by pre-allocating the first memory page before an application is launched. This technique allows to prevent Null pointer attacks that can be exploited in certain programs.
Note: EMET only works in user mode, it thus cannot prevent NULL deference attack at kernel mode level.
#4 - Heap spray allocation
This mechanism allows to prevent attacks exploiting the memory region used for dynamic allocation (the heap). These attacks have the characteristic to pre-to allocate multiple memory areas to store multiple copies of malicious code (generally a shellcode). By multiplying the occurrences of malicious code (spray effect), the malicious program increases the probability of the code being executed.
The pre-allocation of memory pages by EMET blocks the heap spray attacks, since the memory regions are already allocated.
#5 - Mandatory ASLR
Certain malicious programs are able to predict the allocated address space of dynamic libraries (DLL) loaded in memory by an application. This can help them circumvent DEP protections. This kind of attack is commonly called ROP (Return Oriented Programming) attack. In order to fight against this kind of attack, EMET uses the ASLR (Address Space Randomization Layout) mechanism.
The ASLR technique allows to load modules at randomly chosen memory addresses so that the malicious codes cannot predict the address space used by modules. The difficulty of such a technique is that all the loaded modules must be specifically compiled to use it.
Note: The ASLR function is only available on Windows Vista, Windows server 2008, Windows server 2008 R2 and Windows 7.
#6 - Export Address Table Access Filtering (EATAF)
Certain malicious programs use iteration functions to crawl through the memory address space of EAT (Export Address Table) structures of the system, in order to locate modules loaded in memory. Once a module is located, the malicious code seeks for the address of an API of interests, in order to exploit its payload.
The EATAF mechanism consists in filtering the read and write accesses to EAT tables in order to prevent any malicious program from exploiting the API of these modules, generally “kernel32.dll” or “ntdll.dll”.
EMET functioning modes
Upon launching EMET it displays the available protection techniques on the system, and also the currently running processes. It is then possible to directly customize protections thanks to the GUI interface.
Concretely, EMET has 3 operating modes.
The first mode allows to establish a list of applications to be protected. On a per application basis it is possible to enable or disable the chosen protections (Opt In/Opt out subscription). This flexibility allows to adjust parameter settings of protections and in particular makes it possible to avoid side-effects with “non compatible” applications.
The second mode allows to apply DEP, SEHOP and ASLR protections globally on the operating system. Consequently all the applications benefit implicitly from the protections.
Note: However this mode does not allow the activation of all protections since SEHOP and ASLR techniques are not available on Windows XP and Windows Server 2003 systems.
The last mode of EMET is the command line mode. This one allows administrators to specifically deploy protection policies thanks to script files.
Conclusions
The security features brought by the last version of EMET offer new horizons to fight against malicious programs. Version 2.0 shows in particular many advantages compared to the preceding one:
- No recompiling needed: Until now a preventive measure such as DEP required the applications to be recompiled in order to be protected. Now, EMET allows the use of DEP on application with no recompiling needed. This is very interesting in the case of deployment of protection measures in an enterprise for applications and software for which one does not have the source codes.
- Configuration and ergonomics: EMET offers a very simple GUI interface, which allows a better granularity in terms of configuration settings and in particular, on the choice of applications or processes likely to be protected. It is possible to configure the compatible and non compatible applications with respect to protections (DEP, ASLR, SEHOP).
- Hardening of old applications: EMET allows the management of old applications (legacy) not developed to take advantage of native protections of latest systems. It reduces the exposure cover of these applications regarding the risk of exploitation of vulnerability unknown at the time of their development.
- Scalability: EMET developers plan to adapt the tool to new attack techniques that hackers might use. They wish to evolve the tool by integrating new protection methods.
New methods are already in the course of testing, but their deployment and their real effectiveness are not yet sufficiently validated. An internal function will make EMET able to be updated and to integrate these new technologies as they are developed.
Although the tool presents many assets, it is thus advisable to be careful on generalizing its use on user workstations. Few points should be considered:
- In term of security: The available protection techniques seem effective in certain contexts of attacks, nevertheless one can think that the techniques used by attackers will evolve to adapt to the countermeasures of systems.
- In term of development: One should keep in mind that even if EMET has many advantages, its use should not justify developers to neglect or to give up secure developments best practices.
- In term of deployment: It is important to note that the protection techniques used by EMET are extremely dependent on the operating systems and the applications to be protected.
Certain protections are not appropriate for certain type of programs (firewall, antivirus, old 16bits applications, etc). Microsoft warns about its use with certain “old legacy” applications or low level applications, which could stop functioning (in particular with the ASLR).
The lack of feedbacks from the community does not allow at the moment to guarantee the harmlessness of the tool, neither on the operating system nor on the applications. As well as for the installation of any new applications on a workstation, EMET must be qualified in the user environment before considering its deployment.