The old saying goes “You learn something new every day.” Yesterday, Ed Bott and others helped me to learn about the Microsoft Enhanced Mitigation Experience Toolkit (aka EMET). This free download enables users or IT departments to add extra layers of protection to software that otherwise might remain vulnerable to attack. Not coincidentally what with a slew of zero-day exploits in the recent news, Internet Explorer is amenable to extra protection from EMET that might be well worth adding to whatever mix of anti-malware and security software you already have in place on your Windows machines.
The download is a mere 6.0 MB in size, and both quick and easy to download and install. It also works with Group Policy settings and is thus Active Directory friendly as well. It’s absolutely true some of the program’s security settings are available in other forms, but these generally require access to (and recompiling) source code to be put to work, whereas EMET can protect applications with no need for source code access and recompilation. As the MS Download page says “This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available.” To that latter end, recompiling IE isn’t an option for most of its users, so EMET’s protection comes doubly welcome.
The program’s Application Configuration screen lists the mitigations that EMET can wrap around already-installed programs on Windows PCs:
Here’s a little more information on the seven mitigations, in the same order in which they appear in the preceding screen capture:
- DEP (Data Execution Prevention): a method for invoking modern processor-level protections that block segments of information labeled as data from being executed as a series of processor instructions. Enabling DEP helps stymie dangerous and frequent attacks based on buffer overflow and other techniques that seek to trick computers into executing instructions included in Web page or program input.
- SEHOP (Structured Exception Handler Overwrite Protection): Introduced with Windows Vista, and present in all more modern forms of Windows, this setting blocks exploits that seek to overwrite exception handling routines with their own (rogue) code, especially in older programs that may not have been able to use a /SAFESEH compile setting when compiled. See this Uninformed.org discussion for more details.
- NullPage: Allocates the first page of memory — a predictable and obvious target for malware attacks — before a program is initialized, then blocks attackers from seeking to exploit NULL references in user mode. This prevents attackers from exploiting known and obvious code entry points, or using empty/null values or entries to open applications to various forms of attack.
- HeapSpray: Frequent use of address randomization techniques makes it hard for attackers to predict (or insert) their own code at known addresses within the runtime environment for vulnerable applications. The heap is a working area of memory available to running programs that attackers “seed” with injected code at a wide variety of known addresses — hence the term “heapspray” — that they can attempt to access, one location at a time, if they gain a toehold within an application. This technique prevents such injections by pre-allocating memory addresses to block them from illicit use.
- EAF (Export-Address-Table Access Filtering): This is a table of addresses that program modules use to call various Windows application programming interfaces or APIs. For a module to call an API, it must know the address at which the API has been loaded. To this end, such code works through the export table for all loaded modules, seeking out elements that reference useful or interesting functions (often this involves the kernel32.dll or ntdll.dll modules). This technique filters access to the Export Address Table (EAT), and permits or denies read/write access based on the calling code. If EMET is in use, illicit code will be blocked when it seeks to look up or use APIs it needs to execute its payloads.
- MandatoryASLR (ASLR = Address Space Layout Randomization): In general, ASLR randomizes the addresses where modules are loaded to prevent attackers from using data stored at predictable locations. Normally, using ASLR requires a program to use compile-time flags, but EMET forces modules to load at randomized locations, regardless of compilation flags used. This foils all kinds of attacks based on known address, or address prediction techniques.
- BottomUpASLR (ASLR = Address Space Layout Randomization) Randomized base addresses for bottom-up memory allocations — such as for heaps, stacks, and other commonly used memory structures in programs — so that attackers cannot predict or manipulate these structures for their own purposes.
EMET works with Windows XP at SP3 and higher, Vista SP 1 and higher, and all versions of Windows 7 and 8. It also works with Windows Server 2003 SP1 and higher, Windows Server 2008 (and R2) at all service packs, and Windows Server 2012 (which doesn’t have any Service Packs at this writing, the product only having attained GA status earlier this month on 9/4/2012).
Again, EMET is quick and easy to download and install. The companion User’s Guide explains how to use it through a GUI interface, via Group Policy, or at the command line. Interested readers will also find Ryan Naraine’s and Ed Bott’s coverage of this tool quite useful as well. And don’t forget: it’s free!