New vulnerability affecting Internet Explorer 8 users

Today, the MSRC released Security Advisory 2794220 alerting customers to limited, targeted attacks affecting customers using Internet Explorer 6, 7, and 8. Internet Explorer 9 and Internet Explorer 10 users are safe.

More information about the vulnerability and exploit

In this particular vulnerability, IE attempts to reference and use an object that had previously been freed. The components of an exploit for such a vulnerability are typically the following:

• Javascript to trigger the Internet Explorer vulnerability
• Heap spray or similar memory preparation to ensure the memory being accessed after it has been freed is useful
• A way around the ASLR platform-level mitigation
• A way around the DEP platform-level mitigation

We’ve analyzed four exploits, all the targeted attacks we have seen. They are all very similar:

• Obfuscated Javascript to trigger the vulnerability
• Flash ActionScript-based heap spray
• ASLR bypass using either Java6 MSVCR71.DLL or Office 2007/2010 hxds.dll (http://www.greyhathacker.net/?p=585)
• DEP bypass via chain of ROP gadgets (different ones depending on ASLR bypass)

Ways to block code execution

The best protection against exploits for this vulnerability is for the vulnerable code to not be present. Internet Explorer 9 or 10 do not include the vulnerable code. And the IE team is working around the clock to develop a security update to address this vulnerability for earlier versions of the product. However, until the update is available, customers using Internet Explorer 8 can block the current targeted attacks by introducing changes to disrupt any of the elements of the exploit. Specifically:

• Disabling Javascript will prevent the vulnerability from being triggered initially.
• Disabling Flash will prevent the ActionScipt-based heap spray from preparing memory such that the freed object contains exploit code.
• Disabling the ms-help protocol handler AND ensuring that Java6 is not allowed to run will block the ASLR bypass and the associated ROP chain.

Another alternative - one likely to have less impact on your browsing experience - is to install EMET and enable it to protect Internet Explorer. EMET’s Mandatory ASLR mitigation will block both the Java6-based and hxds.dll-based ASLR bypass. EMET’s Export Address Filtering (EAF) mitigation blocks the shellcode used in the targeted attacks we have analyzed. EMET 3.5’s ROP mitigation blocks both the Java6 and hxds.dll ROP chains used in the exploits we have analyzed.

Appcompat shim-based protection tool available for testing

We’re also working on an appcompat shim-based Fix It protection tool that can be used to protect systems until the comprehensive update is available. The shim does not address the vulnerability but does prevent the vulnerability from being exploited for code execution by making a two-byte change to mshtml at run-time (replaces a je instruction with a jmp). To explain why this shim works to prevent the vulnerability from being exploited, we need to explain more about the vulnerability itself.

First, here is where the object is deleted:

mshtml!CBase::SubRelease+0x1b:
62088d79 8b01            mov     eax,dword ptr [ecx]  ds:0023:0b8d1520
                                 ={mshtml!CButton::`vftable' (61ec6678)}
62088d7b 6a01            push    1
62088d7d ff500c          call    dword ptr [eax+0Ch]  ds:0023:61ec6684
                                 ={mshtml!CButton::`deleting destructor' (622e6773)}

And then here is where the object is reused:

mshtml!CMarkup::OnLoadStatusDone+0x4bd:62067d0a e8b07d0600 call mshtml!CElement::FindDefaultElem (620cfabf) 

62067d0f 8bf8            mov     edi,eax ; eax=0b8d1520
62067d11 3bfe            cmp     edi,esi
62067d13 0f85915d0000    jne     mshtml!CMarkup::OnLoadStatusDone+0x4d0 (6206daaa) [br=1]
mshtml!CMarkup::OnLoadStatusDone+0x4d0:
6206daaa 8b07            mov     eax,dword ptr [edi]  ds:0023:0b8d1520=0c0dab10 !!!

That sequence results in the following:

6206daac 57              push    edi
6206daad 8975c4          mov     dword ptr [ebp-3Ch],esi
6206dab0 8975d4          mov     dword ptr [ebp-2Ch],esi
6206dab3 8975dc          mov     dword ptr [ebp-24h],esi
6206dab6 8975d8          mov     dword ptr [ebp-28h],esi
6206dab9 8975e0          mov     dword ptr [ebp-20h],esi
6206dabc 8975e4          mov     dword ptr [ebp-1Ch],esi
6206dabf ff90dc000000    call dword ptr [eax+0DCh]ds:0023:10ab0de8=????????

In this case, eax is controlled by the following Javascript:

window.location = unescape("%u0d0c%u10abhttps://xxx_redacted_xxx");

We developed an appcompat shim that modifies in memory the mshtml!CElement::FindDefaultElem function to always return NULL, resulting in a safe Internet Explorer crash instead of code execution when IE encounters this exploit. Because the function returns NULL, there is no freed object access the exploit fails to work. This shim may have the side effect in some circumstances of the default form button not being selected by default.

The shim is currently being packaged and code-signed as a one-click, deployable Microsoft Fix It tool. We are releasing the sdb itself today for testing if you’d like to get an early look at the Fix It tool mechanism before the final tool is available. The shim works for the latest version of Internet Explorer 6, 7, and 8. It will have no effect if installed on systems where earlier or later versions of Internet Explorer are installed. The shim targets specific mshtml.dll versions so it will deprecate itself when the official update is installed through Windows Update. However, we recommend uninstalling it after it is no longer needed, due to a minor performance impact at application startup.

The 32-bit and 64-bit shims are attached to this blog post and also available at the following URLs:

• mshtml_shim32.sdb (SHA1: 695750970F6595D247FA30775579BD22E034252B)
• mshtml_shim64.sdb (SHA1: 29444332522F8F06A88953071B3BA13C14FBD70A)

sdbinst –p mshtml_shim32.sdb

sdbinst –p mshtml_shim32.sdb
sdbinst –p mshtml_shim64.sdb

sdbinst –u mshtml_shim32.sdb

sdbinst –u mshtml_shim32.sdb
sdbinst –u mshtml_shim64.sdb

Detecting (failed) exploit attempts against Internet Explorer 9 and 10

Attempts to exploit this vulnerability against IE9 and IE10 will be ineffective for the attacker. However, an astute defender can potentially discover that an IE9 or IE10 system they manage has been targeted using this vulnerability. A key element of the vulnerability trigger is the following:

window.location = unescape("%u0d0c%u10abhttps://www.example.com…)

On systems where the vulnerability is not present, this Javascript snippet will have the side effect of initiating an HTTP GET request with the encoded heap spray address in it. A network log or proxy log would reveal the following HTTP requests:

GET /exploit.html HTTP/1.1
GET /%E0%B4%8C%E1%82%ABhttps://www.example.com HTTP/1.1

As you can see, the value 0x10AB0C0D is encoded in UTF8 and sent as part of the HTTP request. The real-world exploits do not use example.com and the heap spray address will vary depending on targeted OS platform and exploit mechanism but if you see encoded memory addresses in your proxy log, you should investigate to determine whether your organization has been targeted.

Conclusion

We want to reiterate the IE9 and IE10 are not affected and that we currently see only very targeted attacks. And we’re working around the clock on the full security update. You should next expect to see an update from us announcing the availability of a Fix It tool to block the vulnerable code paths. In the meantime, feel free to reach out to us with any questions on the above. You can contact us at switech@microsoft.com.

Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.

- Cristian Craioveanu and Jonathan Ness, MSRC Engineering