Introduction
EMET 5.0's Tech Preview was released this week. Unfortunately, I'm sticking with EMET 4.1.
Crashes
This release has a bug that causes every process it protects to crash when you close that process. This is true for at least Windows 7 x64. You'll get the standard WER dialog. So don't use this release yet. The real release should fix this so we'll ignore this bug in this discussion, but it's odd they released this at all. They must have had pressure to get it out for RSA.
New Protections
This release introduces two new protections: EAF+ and ASR. It also set the Deep Hooks to default on.
EAF+
EAF+ builds on EAF (Export Address table Filtering). I view EAF as being a weaker protection. Conceptually, the idea of understanding the things shellcode is likely to do and blocking them is useful and worthwhile, but it's often a cat and mouse game. EAF worked by using 2 of the 4 debug registers that exist on a system to "hook" any read access to locations that enable you to read the exported functions of ntdll.dll and kernel32.dll. You have only four registers in total that you can use to make these "hooks" but there are more than four ways of finding these export addresses, so these watch the most common path.
EAF+ builds on EAF by additionally protecting access to kernelbase.dll, so this is sort of like applying the "Deep Hooks" concept of EMET to EAF. This now uses 3 of the 4 debug registers. It also does additional checks whenever these locations are read to try to better identify if this is a read by shellcode.
EAF+ also includes black-listing capabilities for specific DLLs that should never be allowed to read the protected locations. You have to manually configure which DLLs you want to black-list on a per-process basis by modifying the registry or importing an XML file with your rules. The default XML protection profile only protect IE, and denies the following DLLs:
- mshtml.dll: The main DLL used by IE to render HTML.
- flash*.ocx: Adobe Flash
- jscript*.dll: Javascript scripting engine.
- vbscript.dll: VBscript scripting engine.
- vgx.dll: VML (Vector Markup Language) renderer.
Despite EAF+ stengthening EAF, it does not protect against any of the known EAF bypass techniques (from Skywing, Aaron Portnoy, and Piotr Bania, as described in my EMET 4.1 Uncovered paper). My personal opinion is this mitigation feature should be abandoned.
ASR
ASR (Attack Surface Reduction) is simply a way to stop DLL's associated with plugins from loading into processes. For example, one of the default rules blocks Flash from loading into Excel. This is a good protection. The default protections are:
- Internet Explorer (these DLLs are only allowed to load for Intranet and Trusted content, not content from the Internet, local system, or Untrusted zone)
- npjpi*.dll: Old Java plugin
- jp2iexp.dll: Java plugin
- vgx.dll: VML renderer
- flash*.ocx: Adobe Flash
- Word and Excel
It's good to see EMET outright denying any use of Flash or Java in Internet Explorer anymore. I've been running without either of those for over a year now and rarely find a site that needs those. By making use of trusted zones though, EMET still allows you to use those plugins in special cases, such as accessing your online bank.
It's odd EMET isn't blocking Flash in other Office products, such as PowerPoint.
Alert overload
If you have Flash installed and you visit almost any major site that does still have some Flash content (like youtube.com which defaults to Flash initially and then falls back to HTML5), then everytime you bring up your browser, EMET will show an alert that it's blocked Flash. From a usability stand-point this is not good, because you ultimately become accustomed to seeing an EMET alert pop-up constantly so you will begin to ignore them. Unfortunately you can't disable the pop-ups on a per-protection basis, so I can't set EMET to hide any ASR alerts while still informing me of any other type of alert.
Configuration complexity
For the ASR protections, if you want to deny Java from loading into Firefox or Chrome, your only option is to modify the default XML protections file to include these rules, and then you'll want to check your registry to ensure these were set correctly, since you can't see these configruations in the GUI.
In the GUI, you are misled into a sense of false protection when you click to enable ASR protection on any processes. EMET never tells you when it's protections will have no affect. For example, enabling the ROP protections on a 64-bit process will do nothing.
Although EMET users are largely more advanced users, I suspect very few will attempt to properly configure ASR on any processes. EAF+ also has special black-listing protections that can only be set through XML importing.
I would like to see either EMET improve it's UI and configurability, or provide more documentation for Enterprise deployments so an admin can learn how to set custom configurations.
Conclusion
EMET 5.0 Tech Preview has a bug that causes crashes, so don't use it. The direction of EMET 5.0 for default enabling Deep Hooks and it's ASR concept is good. It's EAF+ protection adds little value and EMET still suffers from usability problems.
Call to action
For any enterprise admins that read my blog, I think the Internet would get a lot of value from a write-up on how to feed EMET's event logs into Splunk or another SIEM and how you've managed to deploy EMET in an enterprise with your own custom protection rules. If you work for a company that sells an SIEM, do your company, and the Internet a favor, and post this!