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:

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

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 [email protected] 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)