Damage limitation
Mitigating exploits with Microsoft's EMET
by Daniel Bachfeld
Security vulnerabilities in applications have become an everyday problem. Microsoft's Enhanced Mitigation Experience Toolkit (EMET) activates extra protection mechanisms included in recent versions of Windows, which are able to frustrate many attacks. However, getting the configuration right can sometimes be harder than you might think.
EMET is able to thwart or at least reduce the reliability of a range of attack techniques based on exploitation of security vulnerabilities. The technologies used to achieve this include data execution prevention (DEP) and address space layout randomisation (ASLR).
Windows leaves it to the application to indicate whether it wishes to use these mechanisms through the use of specific flags. Many applications fail to use DEP or ASLR, despite the fact that they could do so in theory. EMET allows these protection mechanisms to be activated retrospectively for compiled binaries without requiring access to the source code.
DEP prevents attackers from executing code written to the stack or heap via buffer overflows – the buffer overflow itself cannot be prevented. But attackers don't necessarily execute their own code straight away. By manipulating return addresses, they can return to a code segment already loaded by the application. Attackers usually try to return to specific functions in the C library (return-to-libc attacks). Because these functions are always loaded in the same memory locations, an attacker knows where in the code he needs to return to.
Address Space Layout Randomisation (ASLR) is aimed at preventing attackers from being able to make this prediction. Windows 7 and Vista load process code, associated DLLs, the stack and the heap to random addresses. There are tricks available to get around this, but it does make exploits less reliable and attackers often only get one shot.
EMET also protects against overwriting structured exception handlers (SEH) on the stack or in the data segment. In contrast to overwriting return addresses using buffer overflows, in this attack scenario attackers execute their code by misdirecting function pointers. Microsoft aspires to prevent this by means of structured exception handler overwrite protection (SEHOP). As further protection, EMET allocates the first page in memory (the zero page) of an application in order to render certain exploits, which rely on accidentally accessing null pointers, harmless. EMET's export address table access filtering (EAF) blocks injected shellcode from accessing specific APIs. Anti heap spraying functionality prevents attackers from spraying malicious code to multiple memory locations (as used in the do nothing loop in CSI:Internet).
In combination, these additional protective features can block exploits which have wormed their way past DEP and ASLR. In Windows XP, this renders the recently disclosed exploit for the CoolType vulnerability in Adobe Reader harmless, as we will show next.
Next: Putting it into practice