Last year at Black Hat Las Vegas, we announced the BlueHat Prize contest – a large cash prize awarded for defensive security research. One month ago, we announced the names of three finalists. On Thursday night shortly after 10 PM, at the Microsoft Researcher Appreciation Party, we will unveil which finalist won which prize – the grand prize of $200,000 USD, the second prize of $50,000 USD, and the third prize of an MSDN subscription, valued at $10,000 USD. We are excited to reveal this to the finalists and to the world live at the same time.
Having said that, each of these winning submissions demonstrated creative ways that help increase the difficulty of exploiting memory safety style vulnerabilities, allowing for arbitrary code execution. We wanted to put these novel ideas to work right away to help protect customers. To that end, today we are announcing that a new version of EMET incorporates several ideas from one of the contest finalists and is available for immediate download: EMET 3.5 Tech Preview.
In this blog post we are going to take a look at the new updates and mitigations that are implemented in EMET 3.5 Tech Preview. Please note this is a “tech preview” release intended to evaluate the application compatibility risk of several mitigation ideas in real-world scenarios. EMET 3.0 is ready for wide-spread enterprise adoption. EMET 3.5 Tech Preview is available to help us field test these new ideas in real-world environments.
In this release, we implemented four ROP mitigations that we selected from the BlueHat Prize submissions.
The new ROP mitigations
We have implemented four new ROP mitigations in this tech preview version. Some of the mitigations we received in the BlueHat submission were not original (please see the following section) but can provide protection against many current exploits. The “Execution flow simulation mitigation” (described below) was the main novel contribution in this submission.
Previous work on ROP mitigations
Some of the mitigations we implemented have already been addressed by the security community. For example, Piotr Bania wrote a nice paper about ROP mitigations which can be found here: http://kryptoslogic.com/download/ROP_Whitepaper.pdf
Mitigations description
The ROP mitigations rely on the fact that at some point the ROP chain will need to call certain critical functions (VirtualAlloc, VirtualProtect, HeapCreate, LoadLibrary, etc…) before they transfer execution to the shellcode. EMET will filter all calls to those critical functions and perform the following checks:
Caller checks mitigation
EMET will make sure that when a critical function is reached, it is reached via a “call” instruction rather than a “ret” instruction. This is a very useful mitigation and breaks many ROP gadgets. This mitigation may be incompatible with some programs so use it with caution.
Execution flow simulation mitigation
This mitigation tries to detect ROP gadgets following a call to a critical function. It works by emulating a specified number of instructions at the return address of the caller of a critical function. The number of instructions to emulate can be configured manually by editing the desired application’s registry key and creating the “SimExecFlowCount” DWORD value as shown below:
By default, 15 instructions are simulated. Like the “Caller checks”, this mitigation may not be compatible with all programs.
Stack pivot mitigation
This mitigation is very useful and is used to detect if the stack has been pivoted. It is compatible with most programs, so it is safe to enable it by default.
Special function checks
The special function checks mitigation is split into:
- Load library checks
- Memory protection checks
The former validates calls to load library to see if it comes from a ROP gadget or shellcode, while the latter aims at preventing any attempts to change the protection of stack area for a given thread.
Changes in the user interface
Because the total number of mitigations in EMET grew and do not nicely fit in one screen anymore, we decided to group the mitigations into tabs. The screenshot below shows the new ROP mitigations:
We also added a context menu item in the notifier tray icon that allows you to easily launch EMET graphical interface:
Enabling the ROP mitigations
The ROP mitigations are disabled by default, you have to explicitly enable them. It is possible to import a preconfigured set of applications from the “Application Configuration” dialog:
Select File/Import and then navigate to “[EMET_Install_Folder]\Deployment\Protection Profiles” and choose “All.xml”. To enable certain ROP mitigations for all applications, just edit the “DefaultConfig/Mitigations” node and set the desired ROP mitigations to “true”:
When a ROP attempt is detected, EMET will show you a tooltip and create an event log entry:
Additionally, in this tech preview version, EMET will display a message box with more details about the detected ROP attempt and will present you with a choice to continue (ignoring the ROP checks) or terminate the process. We present the user with this dialog so that if a false positive was detected EMET won’t terminate your application immediately. The confirmation dialog looks like this:
ROP mitigations in action
We tested EMT 3.5 against a bunch of public ROP exploits. The following screenshot shows how EMET 3.5 TP mitigates against Metasploit’s ms12_037_same_id :
Here we see how EMET blocks CVE-2010-0188 (LibTIFF):
A Note about Application Compatibility
Security mitigations carry an application compatibility risk with them. Some applications rely on precisely the behavior that the mitigations block. For this reason mitigations are typically turned off by default and require opt-in from a developer before they are enabled. While EMET allows users to override this, it is important to be aware of the risk. EMET is intended for tech savvy users such as IT professionals and security researchers who can troubleshoot issues that these mitigations may introduce. We also recommend testing your applications and use scenarios with these mitigations prior to deploying them on any production systems.
Known limitations
As stated above, as long as one of the critical functions is called then ROP checks will take place. It is possible for the attacker to circumvent this by not calling any of the hooked functions (for example directly calling into NTDLL and not kernel32) or just circumventing the hook. The following Phrack article presents many attack vectors that can be used to break those mitigations: http://www.phrack.org/issues.html?issue=62&id=5
Feedback
EMET 3.5 TP requires uninstalling previous versions of EMET first. Previously configured applications and rules will be retained and will work again after installing EMET 3.5 TP.
We encourage you to download and try out this release. Any feedback or comments are welcome; you can reach us at switech@microsoft.com.
Acknowledgements
I would like to thank the MSRC engineering and the science team, in particular: Chengyun Chu, Suha Can, Elia Florio.
Elias Bachaalany, MSRC Engineering