Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

February, 2014

  • Announcing EMET 5.0 Technical Preview

    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.

    Attack Surface Reduction

    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.

    EAF+

    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.

    Other improvements

    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.

    Acknowledgments

    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

  • Fix it tool available to block Internet Explorer attacks leveraging CVE-2014-0322

    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:

    • Platforms affected
    • Steps you can take to stay safe
    • More details about the vulnerability
    • More details about the Fix It tool

    Platforms Affected

    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:

      Windows XP
    Server 2003
    Windows Vista
    Server 2008
    Windows 7
    Server 2008 R2
    Windows 8
    Server 2012
    Windows 8.1
    Server 2012 R2
    Internet Explorer 6 Not vulnerable n/a n/a n/a n/a
    Internet Explorer 7 Not vulnerable Not vulnerable n/a n/a n/a
    Internet Explorer 8 Not vulnerable Not vulnerable Not vulnerable n/a n/a
    Internet Explorer 9 n/a Vulnerable,
    not under attack
    Vulnerable,
    not under attack
    n/a n/a
    Internet Explorer 10 n/a n/a Under attack Under attack n/a
    Internet Explorer 11 n/a n/a Not vulnerable n/a Not vulnerable

    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:

    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

    CVE-2014-0322 describes an mshtml.dll use-after-free vulnerability involving the CMarkup object being accessed after it has been freed. As described above, this vulnerability is present in both Internet Explorer 9 and Internet Explorer 10 but exploits we have seen target only 32-bit Internet Explorer 10. The exploit was explained in greater detail on the FireEye security blog. To recap, it uses Javascript to trigger the use-after-free condition and then uses Flash to convert a write primitive into a read/write primitive that enables DEP and ASLR to be bypassed. The primitive conversion happens by redirecting a write based on a freed object’s data (which has now been reallocated by the attacker) to corrupt a size field inside a Flash object. The corrupted size field in the Flash object is used to read and write outside of the object’s boundary, allowing discovery of module addresses in Internet Explorer’s Address Space. We are not aware of any elevation of privilege or sandbox escape vulnerability being used to “break out” of the Internet Explorer Protected Mode sandbox. Therefore, even after the exploit gains code execution, it still needs a non-trivial element to result in a persistent compromise of the computer.

    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
    MSHTML!CMarkup::InsertElementInternal:
    e9d3d2a500      jmp     MSHTML!SZ_HTMLNAMESPACE+0xf (66bb43c7) // we redirect execution
    
    0:020> u 66bb43c7
    MSHTML!SZ_HTMLNAMESPACE+0xf:
    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.

    Acknowledgements

    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.

    Conclusion

    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 secure@microsoft.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)

  • Assessing risk for the February 2014 security updates

    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.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Likely first 30 days impact Platform mitigations and key notes
    MS14-010

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Addresses both memory corruption vulnerabilities and elevation of privilege vulnerabilities in a single package.
    MS14-011

    (VBScript)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. The single CVE addressed by this bulletin is included in MS14-010 for IE9 users. Customers with IE9 installed need not deploy MS14-011.
    MS14-007

    (DirectWrite)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Internet Explorer is vector to this vulnerability in DirectWrite.
    MS14-005

    (MSXML)

    Victim browses to a malicious website to be exposed to this information leak vulnerability. Important 3 Vulnerability first seen as ASLR bypass mechanism in targeted attacks during November 2013. May see attacks again begin using this again as details emerge. As discussed in the SRD and FireEye blogs during November 2013, this vulnerability was used along with another vulnerability in active attacks. The MS13-090 security update completely blocked all attacks described by those blog posts.
    MS14-009

    (.NET Framework)

    Most likely to be exploited vulnerability involves attacker initiating but not completing POST requests to ASP.NET web application, resulting in resource exhaustion denial of service. Important 1 Resource exhaustion attacks involving CVE-2014-0253 already in progress in the wild. CVE-2014-0253 addresses resource exhaustion “Slowloris” attack.

    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.

    MS14-008

    (Forefront Protection for Exchange)

    Code is unlikely to be reachable. However, if attackers do find a way, it would involve a malicious email message being processed by the Forefront Protection for Exchange service. Critical 2 Unlikely to see exploits developed targeting this vulnerability. While this vulnerability’s attack vector appears attractive (email), the vulnerability is unlikely to be reachable. It was discovered internally by code analysis and we have not been successful in developing a real-world vulnerability trigger. We address it via security update out of an abundance of caution.
    MS14-006

    (IPv6)

    Attacker on the same subnet as victim (IPv6 link-local) sends large number of malicious router advertisements resulting in victim system bugcheck. Important 3 Denial of service only. This bugcheck is triggered by a watchdog timer on the system, not due to memory corruption. Affects Windows RT, Windows Server 2012 (not R2), and Windows 8 (not 8.1).

    - Jonathan Ness, MSRC