Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Today, we are thrilled to announce a preview release of the next version of the Enhanced Mitigation Experience Toolkit, better known as EMET. You can download EMET 5.0 Technical Preview here. This Technical Preview introduces new features and enhancements that we expect to be key components of the final EMET 5.0 release. We are releasing this technical preview to gather customer feedback about the new features and enhancements. Your feedback will affect the final EMET 5.0 technical implementation. We encourage you to download this Technical Preview, try it out in a test environment, and let us know how you would like these features and enhancements to show up in the final version. If you are in San Francisco, California, for the RSA Conference USA 2014, please join us at the Microsoft booth (number 3005) for a demo of EMET 5.0 Technical Preview and give us feedback directly in person. Several members of the EMET team will be demonstrating at the Microsoft booth for the entire Conference.
As mentioned, this Technical Preview release implements new features to disrupt and block the attacks that we have detected and analyzed over the past several months. The techniques used in these attacks have inspired us with new mitigation ideas to disrupt exploitation and raise the cost to write reliable exploits. The EMET 5.0 Technical Preview also implements additional defensive mechanisms to reduce exposure from attacks.
The two new features introduced in EMET 5.0 Technical Preview are the Attack Surface Reduction (ASR) and the Export Address Table Filtering Plus (EAF+). Similar to what we have done with EMET 3.5 Technical Preview, where we introduced a new set of mitigations to counter Return Oriented Programming (ROP), we are introducing these two new mitigations and ask for your feedback on how they can be improved. Of course, they are a “work in progress.” Our goal is to have them polished for the final version of EMET 5.0.
Let’s see in detail what these two new mitigations do, and the reasoning that led us to their implementation.
In mid-2013, we published a Fix it solution to disable the Oracle Java plug-in in Internet Explorer. We received a lot of positive feedback and a number of suggestions on how we could improve the Fix it. The most recurring suggestion we received was to allow the Oracle Java plug-in on intranet websites, which commonly run Line-of-Business applications written in Java, while blocking it on Internet Zone websites. In addition to that Java-related customer feedback, we have also seen a number of exploits targeting the Adobe Flash Player plug-in. For example, the RSA breach was enabled by an Adobe Flash Player exploit embedded inside a Microsoft Excel file and a number of targeted attacks have been carried out by Adobe Flash Player exploits embedded in Microsoft Word documents, as described by Citizen Lab. We decided to design a new feature that can be used to mitigate similar situations and to help to reduce the attack surface of applications. We call this feature Attack Surface Reduction (ASR), and it can be used as a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.
The example below shows ASR in action, preventing Microsoft Word from launching an Adobe Flash Player file embedded in the document. By default, EMET 5.0 Technical Preview comes pre-configured to block certain plug-ins from being loaded by Internet Explorer, Microsoft Word and Microsoft Excel. The feature is fully configurable by changing two registry keys that list the names of the plug-ins to block, and, if supported, the security zones that allow exceptions. For more details on how to configure ASR please refer to the EMET 5.0 Technical Preview user guide.
We also added new capabilities to the existing Export Address Table Filtering (EAF). EAF+ consolidates protection of lower-level modules and prevents certain exploitation techniques used to build dynamic ROP gadgets in memory from export tables. EAF+ can be enabled through the “Mitigation Settings” ribbon. When EAF+ is enabled, it will add the following additional safeguards over-and-above the existing EAF checks:
Add protection for KERNELBASE exports in addition to the existing NTDLL.DLL and KERNEL32.DLL
Perform additional integrity checks on stack registers and stack limits when export tables are read from certain lower-level modules
Prevent memory read operations on protected export tables when they originate from suspicious modules that may reveal memory corruption bugs used as “read primitives” for memory probing
For example, the third protection mechanism in the list above mitigates the exploitation technique developed in Adobe Flash Player used in some recent Internet Explorer exploits (CVE-2013-3163 and CVE-2014-0322), where the attacker attempted to build ROP gadgets by scanning the memory and parsing DLL exports using ActionScript code. Exploits for these vulnerabilities are already blocked by other EMET mitigations. EAF+ provides another way to disrupt and defeat advanced attacks. The screenshot below shows the exploit for CVE-2014-0322 in action on Internet Explorer protected by EMET 5.0 Technical Preview with only EAF+ enabled.
This Technical Preview enables the “Deep Hooks” mitigation setting. We have been working with third-party software vendors whose products do not run properly with Deep Hooks enabled. We believe these vendors have resolved the application compatibility issues that previously existed with Deep Hooks enabled. We enable Deep Hooks in the Technical Preview to evaluate the possibility of having this setting turned on by default in the final EMET 5.0 release because it has proven to be effective against certain advanced exploits using ROP gadgets with lower level APIs. We have also introduced some additional hardening to protect EMET’s configuration when loaded in memory, and fixed several application compatibility issues including a common one that involves Adobe Reader and the “MemProt” mitigation.
We’d like to thank Spencer J. McIntyre from SecureState, Jared DeMott from Bromium Labs, along with Peleus Uhley and Ashutosh Mehra from the Adobe Security team for their collaboration on the EMET 5.0 Technical Preview.
We are excited for this Technical Preview and we hope that the additions are as valuable for our customers as they are for us. We invite you to install and give EMET 5.0 Technical Preview a try; we look forward to hearing your feedback and suggestions on how to enhance the new features that we have introduced. We would also welcome any suggestions for additional new features you’d like to see included in the final version of EMET 5.0. We greatly value the feedback we receive, and we want to build a product that not only provides additional protection to systems but is also easy to use and configure. We then invite you all to download EMET 5.0 Technical Preview and drop us a line!
The EMET Team
Today, we released Security Advisory 2934088 to provide guidance to customers concerned about a new vulnerability found in Internet Explorer versions 9 and 10. This vulnerability has been exploited in limited, targeted attacks against Internet Explorer 10 users browsing to www.vfw.org and www.gifas.asso.fr. We will cover the following topics in this blog post:
As described in Security Advisory 2934088, both Internet Explorer 9 and Internet Explorer 10 contain the vulnerable code. However, we have not seen any exploit code capable of triggering the vulnerability on Internet Explorer 9. The chart below may help explain the risk by platform:
Steps you can take to stay safe
Any of the following three protection mechanisms will protect you from exploits we have seen that leverage this vulnerability for code execution:
1 – Upgrade to Internet Explorer 11
2 – Install the Enhanced Mitigation Experience Toolkit (EMET)
3 – Install the Fix it workaround tool
Upgrading to Internet Explorer 11 is the best way to stay safe from exploit attempts targeting this vulnerability.
The Enhanced Mitigation Experience Toolkit (EMET) is also an effective way to block the targeted attacks we have analyzed. This particular exploit explicitly checks for EMET and refuses to run on any system where EMET is installed. However, even with the exploit’s EMET check removed, the default configuration of EMET blocks the attack. In this particular case, EMET’s EAF and Anti-Detour features block the exploit in the default EMET configuration. With EMET’s “Deep Hooks” feature enabled, the MemProt, StackPivot, and CallerCheck features each independently are capable of blocking this exploit. We are pleased to see EMET continuing to provide protection for a significant portion of memory corruption exploits today. On that note, we found that in the second half of 2013, all in-the-wild exploits that we encountered that have leveraging memory corruption for code execution were blocked by EMET! We recommend that all customers install this tool. Watch next week for an announcement at the RSA Conference about the future of EMET.
The third, and likely easiest way to protect yourself from attempts to exploit the vulnerability, is to install the Fix it workaround tool released in today’s advisory. You can refer to Knowledge Base Article 2934088 for complete details but simply clicking through the “Fix It” installer from the following link will protect your system from attempts to exploit the vulnerability:
Apply Fix it
Uninstall Fix it
Enable the CVE-2014-0322 Workaround
Uninstall the CVE-2014-0322 Workaround
Installing the Fix it does not require a reboot but administrative privileges on the system are required. The Fix it installation will be effective on any Internet Explorer 9 or Internet Explorer 10 system where the most recently-released security update (MS14-010) has already been installed. More specifically, the appcompat shim is enabled for the Internet Explorer process where mshtml.dll is one of the following four versions: 9.0.8112.16533, 9.0.8112.20644, 10.0.9200.16798, or 10.0.9200.20916. The eventual security update that addresses this vulnerability will ship with an incremented mshtml.dll version number, thereby automatically obsoleting this Fix it.
You can read more about previous instances of this temporary workaround technique at http://blogs.technet.com/b/srd/archive/tags/fixit/. Fix its have been a popular mitigation technique with our customers to cover the gap between the time when an exploit appears and the time when a final, comprehensive, fully-tested security update is available for wide distribution. The last instance of a Fix It tool to address an Internet Explorer vulnerability (addressed by MS13-080) was installed on 23 million computers. The most recent security-related Fix it solution mitigated an Office vulnerability that was subsequently addressed by MS13-096. That Fix It solution was installed on 57 million computers. We mention these numbers with the hope of giving you confidence that a number of your IT Pro peers are using Fix it solutions to protect their enterprise network.
More details about the vulnerability and exploit
More details about the Fix it tool
The Fix it redirects execution of two functions, mshtml!CMarkup::InsertElementInternal and mshtml!CMarkup::InsertTextInternal, to the code introduced by the appcompat shim. Similar changes are made in both functions. Let’s take a closer look at mshtml!CMarkup::InsertElementInternal:
0:020> u mshtml!Cmarkup::InsertElementInternal
e9d3d2a500 jmp MSHTML!SZ_HTMLNAMESPACE+0xf (66bb43c7) // we redirect execution
0:020> u 66bb43c7
60 pushad //save registers
8bc8 mov ecx,eax //move the this* pointer to ecx
e818468bff call MSHTML!CMarkup::CLock::CLock+0x2 (664689e7) //call into the code where we AddRef() on this CMarkup object
61 popad //restore our registers
55 push ebp //execute the code we overwrote in the jump to this shim
8bec mov ebp,esp
e91c2d5aff jmp MSHTML!CMarkup::InsertElementInternal+0x5 (661570f4) //jump back to the next instruction after the our redirection point
Similar to the Fix it solution for CVE-2013-3893, the shim leverages slack space near the end of the mshtml.dll’s .text section. Astute readers may notice that the appcompat shim does not introduce any code to reduce the reference count on the CMarkup object. Said another way, the appcompat shim introduces a memory leak. The memory is restored when an IE tab (process) is terminated. This minor side effect of the workaround tool is harmless and of course it won’t be present in the final comprehensive security update for this vulnerability.
Thanks to Richard Van Eeden, Axel Souchet, Chengyun Chu, and Elia Florio for the help triaging this vulnerability and help building the Fix it workaround tool.
Please let us know if you have any questions about the risk posed by this vulnerability, the exploits we have seen leveraging the vulnerability for code execution, or mitigation opportunities available to protect your systems. You can email us at email@example.com with [SRD] in subject line. Or if you plan to attend the RSA Conference in San Francisco, CA next week, feel free to stop by the Microsoft Booth #3005 to talk to us in person. We’re looking forward to announcing EMET news on Tuesday morning.
- Neil Sikka, MSRC Engineering (@neilsikka)
Today we released seven security bulletins addressing 31 unique CVE’s. Four bulletins have a maximum severity rating of Critical while the other three have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
CVE-2014-0257 addresses sandbox escape vulnerability invoving com objects running code out-of-process.
CVE-2014-0295 addresses the vsab7rt.dll ASLR bypass described at http://www.greyhathacker.net/?p=585.
(Forefront Protection for Exchange)
- Jonathan Ness, MSRC