The one security tool every Windows user should know about

A new zero-day security hole in all versions of Windows is the subject of "targeted attacks," Microsoft says. The flaw, according to Microsoft Security Advisory 2488013, occurs when an attacker exploits "the creation of uninitialized memory during a CSS function within Internet Explorer." The result? "It is possible under certain conditions for the memory to be leveraged by an attacker using a specially crafted Web page to gain remote code execution."

Similar holes have been spotted in the past in applications such as Adobe Reader, Adobe Flash, and Apple's QuickTime.

The definitive fix for a vulnerability like this is a vendor-supplied patch. But what do you do while you're waiting for the patch? And how do you deal with vulnerabilities in legacy applications that can't be easily repaired?

That's the goal of Microsoft's Enhanced Mitigation Experience Toolkit (EMET), a simple but powerful configuration utility that allows you to harden applications that weren't originally designed to take advantage of Windows security features. EMET version 2 was released a few months ago and runs on all currently supported Windows client and server editions, including Windows 7, Windows Vista (Service Pack 1 or later), Windows XP (Service Pack 3), Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 (Service Pack 1 or later).

Although it's possible to configure some of these settings in other ways, EMET offers a straightforward, clean interface that works identically across multiple Windows versions. It's not a magic bullet, but it is an extremely potent addition to a thorough, in-depth approach to Windows security.

EMET gives you more granular control over Data Execution Prevention (DEP), a security feature that has been a part of Windows since XP Service Pack 2. Hardware-enforced DEP blocks the execution of code in memory locations that should contain only data, such as the stack or the heap, preventing a common form of exploit. Using EMET, you can turn on DEP for applications that were not originally compiled to be compatible with the feature. (For more on how DEP works, see the two-part "Understanding DEP as a mitigation technology series on the Microsoft Security Research & Defense blog: Part 1, Part 2).

You can also use EMET to overcome a limitation of Address Space Layout Randomization (ASLR). This feature is designed to prevent attackers from jumping to predictable memory addresses to exploit vulnerabilities in code. The problem with ASLR is that it works on a per-process basis; dynamic-link libraries (DLLs) associated with that process can still be located at predictable addresses, where vulnerabilities can be exploited. That's the attack vector used in the unpatched zero-day vulnerability I mention at the beginning of this post. EMET supports mandatory ASLR, which forces the relocation of DLLs associated with a process and thus blocks this entire class of exploits.

Other features in EMET mitigate against common tricks that hackers use to exploit flaws in code, by blocking common "heap spraying" techniques and validating exceptions before calling an exception handler.

The EMET documentation acknowledges that these are stopgap fixes:

Please note this is a pseudo mitigation designed to break current exploit techniques. It is not designed to break future exploits as well. As exploit techniques continue to evolve, so will EMET.

In fact, that's one of the promises of EMET. It exists outside the Windows code base, so it can be updated more aggressively. As the official user's guide explains:

EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from cutting edge mitigations. The release cycle for EMET is also not tied to any product. EMET updates can be made dynamically as soon as new mitigations are ready.

EMET is distributed as a very small (4.7MB) installer and can be downloaded here. In the remainder of this post, I walk you through some of the basics of installation and setup.

Installing Microsoft's Enhanced Mitigation Experience Toolkit (EMET) is straightforward for individual Windows PCs, although Microsoft acknowledges that the current version is "not convenient" to deploy in an enterprise setting. On Windows XP and Windows Server 2003, you must first ensure that the Microsoft .NET Framework 2.0 is installed. There are no prerequisites for other supported Windows versions.

For a step-by-step illustrated walkthrough, see the accompanying image gallery.

After downloading the installer package, log on using an administrator account and run EMET Setup.msi. A restart is not required. Then open the EMET application using its Start menu shortcut.

The EMET interface is divided into two parts. The top shows the system status; the bottom shows a list of running processes and whether they are currently running with EMET enabled.

You can use EMET to adjust systemwide security settings. Click Configure System to display the dialog box shown here. You can configure any of the three settings individually or use the drop-down menu at the top to apply preconfigured groups of settings.

Although it sounds tempting, I don't recommend the Maximum Security Settings option for Windows 7. That's especially true in a business setting, where compatibility issues can have financial consequences. For Windows XP, however, this option does make sense. Your XP options are more limited, because XP doesn't support SEHOP or ASLR. Enabling DEP universally on XP is a smart idea.

Most zero-day threats attack commonly used Internet-facing applications, such as Internet Explorer add-ons, Adobe Acrobat and Reader, Apple QuickTime, and so on. To tighten security on one of these individual programs, click Configure Apps.

Click Add and then browse to the location of the executable file associated with that program. For the default 32-bit versions of Internet Explorer, this is C:\Program Files\Internet Explorer\Iexplore.exe [on 64-bit Windows installations, this file is in the Program Files (x86) folder]. For Adobe Reader, start in Program Files [or Program Files (x86) on a 64-bit Windows system]; the executable file, AcroRd32.exe, is typically in the Adobe\Reader subfolder (this folder name might include a version number as well).

After you add an executable file, it appears in the Application Configuration dialog box, shown here, where you can enable or disable specific mitigations. By default, all options for a given process are selected.

To view the security status of programs, open the main EMET UI and look in the Running Processes list. If you've just added a program, you might have to close and restart it, then click the Refresh button to the right of the Running Processes heading. Click the Running EMET heading to sort the list so that all EMET-enabled apps are grouped together.

I'm interested in hearing feedback from readers who use EMET. Have you noticed specific compatibility issues? Have you checked specific exploits with and without EMET enabled? Leave your comments in the Talkback section or send me an e-mail using the Contact link in my bio, at the bottom of this post.