Recently, Microsoft published a blog post called Moving Beyond EMET that appears to make two main points: (1) Microsoft EMET will no longer support EMET after July 31, 2018, and (2) Windows 10 provides protections that make EMET unnecessary. In this blog post, I explain why Windows 10 does not provide the additional protections that EMET does and why EMET is still an important tool to help prevent exploitation of vulnerabilities.

To compare protections of a Windows-with-EMET system against a stock Windows 10 system, it's important to first enumerate the protections that EMET 5.51 provides:

• Data Execution Prevention (DEP)
• Structured Exception Handler Overwrite Protection (SEHOP)
• Address Space Layout Randomization (ASLR)
• Certificate Trust (Pinning)
• Block Untrusted Fonts (Fonts)

The system-wide DEP, SEHOP, and ASLR settings in EMET are provided by the Windows operating system itself. That is, the benefit of EMET for these settings is simply that it acts as a unified GUI application to make these changes in your system.

• Data Execution Prevention (DEP)
• Structured Exception Handler Overwrite Protection (SEHOP)
• Null Page Allocation (NullPage)
• Heapspray Allocations (HeapSpray)
• Export Address Table Access Filtering (EAF)
• Export Address Table Access Filtering Plus (EAF+)
• Mandatory Address Space Layout Randomization (ASLR)
• Bottom-Up Randomization (BottomUpASLR)
• ROP Mitigations
  
  • LoadLib
  • MemProt
  • Caller
  • SimExecFlow
  • StackPivot
• Attack Surface Reduction (ASR)
• Block Untrusted Fonts (Fonts)

Application-specific EMET mitigations are applied by loading the EMET library into the process space of each protected application when it is launched. Here, the EMET library can modify the behavior of the target application by providing additional protections. The application-specific-protection capability provided by EMET is where EMET really adds value. Because we cannot rely on all software vendors to produce code that uses all of the exploit mitigations available, EMET puts this control back in our hands.

Detailed descriptions of these protections can be found in the EMET 5.5 User's Guide.

To help visualize what EMET can do for us, it is useful to enumerate the exploit mitigations for various Windows versions, both with and without EMET.

When it comes to system-wide mitigations, there's not much of a difference between a Windows system that has EMET installed and a stock Windows system that has had the mitigations enabled manually. This comparison, illustrated in the figure below, makes the true benefit of EMET clear: application-specific mitigations.

Update: December 7, 2016

The purpose of the table below is to draw attention to the application-specific mitigations that EMET provides, but Windows 10 does not provide. Windows 10 includes a number of extra system-level mitigations that Windows 7 with EMET cannot provide. However, as with the recent Firefox vulnerability, application-specific mitigations add protections against exploitation, but the general Windows 10 mitigations may not help. Upgrading to Windows 10 is indeed a good idea from an exploit mitigation perspective, but simply upgrading may not provide enough protection by itself.

It is pretty clear that an application running on a stock Windows 10 system does not have the same protections as one running on a Windows 10 system with EMET properly configured. Even a Windows 7 system with EMET configured protects your application more than a stock Windows 10 system.

The Microsoft Blog entry Moving Beyond EMET makes the following statement:

Windows 10 includes all of the mitigation features that EMET administrators have come to rely on such as DEP, ASLR, and Control Flow Guard (CFG) along with many new mitigations to prevent bypasses in UAC and exploits targeting the browser.

Let's look at the language used and analyze what Microsoft is actually saying and how people may interpret the sentence.

Fact: Windows 10 supports DEP, ASLR, and Control Flow Guard (CFG).
Fiction: Windows 10 makes EMET irrelevant.

Microsoft's statement above overlooks the primary reason for someone to run EMET. In particular, users running EMET to protect applications that do not opt in to all of the exploit mitigations that it should. Even though the underlying Windows operating system supports a mitigation, doing so does not necessarily mean that it will be applied to an application.

Developer adoption of exploit mitigations takes place at a slower rate than we'd like to see. For example, even Microsoft does not compile all of Office 2010 with the /DYNAMICBASE flag to indicate compatibility with ASLR. What is the impact? An attacker may be able to work around ASLR by causing a non-DYNAMICBASE library to be loaded into the process space of the vulnerable application, potentially resulting in successful exploitation of a memory corruption vulnerability. What do we do to protect ourselves against this situation? We run EMET with application-specific mitigations enabled!

Microsoft strongly implies that if you are running Windows 10, there is no need for EMET anymore. This implication is not true. The reason it's not true is that Windows 10 does not provide the application-specific mitigations that EMET does.

Windows 10 does indeed provide some nice exploit mitigations. The problem is that the software that you are running needs to be specifically compiled to take advantage of them. Control Flow Guard (CFG) looks to provide similar protections to the ROP application-specific mitigations in EMET. The problem is that the application needs to be specifically compiled to take advantage of CFG. Out of all of the applications you run in your enterprise, do you know which ones are built with CFG support? If an application is not built to use CFG, it doesn't matter if your underlying operating system supports CFG or not.

Update (November 21, 2016)

Windows 10, version 1607 and Windows Server 2016 do support some application-specific mitigations. In particular, DEP, SEHOP, ASLR, and BottomupASLR. The table above has been updated to reflect this information. Setting these application-specific mitigations requires calculating and setting a bit field value in the Windows registry for each process name that you would like to protect. Please see Override Process Mitigation Options to help enforce app-related security policies for more details.

Microsoft has announced that they will no longer support EMET beyond July 31, 2018. Some may use this end-of-life (EOL) statement as an excuse for not deploying EMET. If this is the case, it would be wise to investigate all of the software that is currently outside of the support window before July 31, 2018.

If you are lucky enough that all of your applications are within their support cycle, EMET provides protections against exploitation of new and unknown memory-corruption vulnerabilities, known as "zero-days."

Microsoft applications that will lose support a year before EMET are listed in Products Reaching End of Support for 2017. Office 2007 is in this list, for example. With such out-of-support applications, it is even more important to provide additional exploit protection with a product like EMET. When a vulnerability is discovered in a product outside of its support cycle, this vulnerability is referred to as a "forever-day." That is, the vulnerability will never be fixed.

Just because Microsoft will stop supporting EMET after July 31, 2018 does not mean that the application will stop working beyond that date. It will likely continue to operate in the same way that it has been working all along. This EOL date simply means that you will not be able to get assistance from Microsoft after that date.

As mentioned earlier, many of the system-wide mitigations exposed by EMET are actually provided by the underlying Windows operating system. The primary mitigations that can be enabled globally are DEP and ASLR.

System-wide DEP can be configured using the BCDEdit utility. Microsoft indicates, "Before setting BCDEdit options you might need to disable or suspend BitLocker and Secure Boot on the computer." To change the DEP setting to AlwaysOn, in a CMD prompt with administrative privileges run

System-wide ASLR can be configured by importing the following registry value:

EMET is not required for setting the above system-wide mitigations for DEP and ASLR. Enabling these features will make Windows more secure than the default configuration. However, the system-wide mitigations are less granular than what is available with EMET. In particular, if an application that you need to run is incompatible with a particular mitigation, it may not be possible to allow that application to run when the system-wide mitigations are in place. On a system with EMET, however, the system-wide mitigations can be relaxed, and compatible application-specific mitigations can be applied on a program-by-program basis.

While EMET itself is a free tool, successful deployment of it takes some work. But there are rewards to be reaped from this work.

• From an exploit mitigation perspective, upgrading to Windows 10 is a good idea.
• Installing EMET with application-specific mitigations configured is also a good idea.
• EMET provides some protection against zero-day vulnerabilities in supported software, as well as forever-day vulnerabilities in unsupported software.
• If the use of EMET is not possible, then the system-wide mitigations of DEP and ASLR can be applied without EMET.
• Windows 10 does not provide all of the mitigation features that EMET administrators have come to rely on.

Please read the blog post Life Beyond Microsoft EMET for updated information about how Windows 10 now includes EMET-like capabilities.