This past weekend we have alerted you about a vulnerability present in Internet Explorer 6, 7, and 8 which has already been used in limited targeted attacks. Later versions of Internet Explorer (9 and 10) are not affected by this issue. As always, we recommend upgrading to the latest available. For those who are constrained to older versions, today we are providing a Microsoft "Fix it" solution designed to reduce the attack surface of this vulnerability.
This code-signed, one-click deployable Microsoft “Fix it” package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time Internet Explorer is loaded. For more details, you can refer to our previous blog post. You can apply this workaround by running the Microsoft Fix it 50971 from the link below. For enterprise deployment, please refer to Knowledge Base article 2794220, section “Deploying an application compatibility database across multiple computers”.
Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, as you are applying the final security update, you should uninstall the workaround as it will no longer be needed.
- Cristian Craioveanu, MSRC Engineering
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:
We’ve analyzed four exploits, all the targeted attacks we have seen. They are all very similar:
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:
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:
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
Update December 31: Fix It tool is available. Please see http://support.microsoft.com/kb/2794220 for download links and details.
Today we released seven security bulletins addressing 12 CVE’s. Five of the bulletins have a maximum severity rating of Critical, and two 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.
(Internet Explorer)
(Word)
(Windows File Handling)
(Windows font drivers - ATMFD & win32k.sys)
(Oracle Outside In for Exchange)
(DirectPlay)
(IP-HTTPS Security Feature Bypass)
- Jonathan Ness, MSRC Engineering
MS12-083 is being released to address a Security Feature Bypass, a class of vulnerability for which we do not frequently release security updates. This is the third such instance, with MS12-001 and MS12-032 previously having addressed Security Feature bypasses. The security feature being bypassed in the case of MS12-083 is the revocation check in IP-HTTPS. This “IP-HTTPS” component is used in Direct Access environments. This vulnerability allows a revoked computer certificate to be accepted for authentication.
What is the security feature being bypassed?
A Direct Access server can be configured to allow a number of different tunneling protocols. One could use Teredo, 6to4, native IPv6, or IP-HTTPS. IP-HTTPS is intended to be the most secure way of connecting to a Direct Access Server as it offers initial client and server authentication. However, in the case of the vulnerability being addressed by MS12-083, the IP-HTTPS server does not properly check client certificates for revocation. This would allow an attacker to use a revoked computer certificate and establish the IP- HTTPS tunnel for further communication.
How severe is the security bypass of IP-HTTPS revocation check?
This attack is only possible with a revoked computer certificate from a certificate authority that is trusted by the IP-HTTPS server. Although this vulnerability allows the creation of the outer IP-HTTPS tunnel with a revoked certificate, valid domain credentials and IPsec tunnel certificate are required to establish the IPsec tunnels (Infrastructure & Intranet tunnels) and access internal resources.
By establishing an IP-HTTPS tunnel to the DA Server, the client will get an IPv6 interface to connect to the DA Server. An attacker could use this interface to see the IPv6 addresses of other clients when these clients perform duplicate IPv6 address detection and other standard IPv6 neighbor discovery. Knowing the IPv6 address of other clients in the network, the attacker could leverage any other network vulnerabilities.
What is the most likely attack scenario?
As described above, this vulnerability allows a client to access the network even after his certificate has been revoked. Therefore, the most likely attack scenario is that of an employee who has been terminated or who has lost physical control of his laptop. In both cases, simply revoking the certificate would provide a false sense of security on systems where this security update has not yet been installed.
How to mitigate this vulnerability?
This security update comprehensively addresses the vulnerability. To mitigate the issue without the security update, we suggest disabling the computer account in Active Directory at the same time the certificate is revoked. Doing so will prevent the IP-HTTPS tunnel from being created.
- Gangadhara Swamy and Ali Rahbar, MSRC Engineering