Security Research & Defense

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

December, 2012

  • Microsoft "Fix it" available for Internet Explorer 6, 7, and 8

    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”.

     

    ApplyUninstall

     

    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

  • 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:

    To Install To Uninstall
    On 32 bit OS run following:
    sdbinst –p mshtml_shim32.sdb

    On 64 bit OS run following:
    sdbinst –p mshtml_shim32.sdb
    sdbinst –p mshtml_shim64.sdb
    On 32 bit OS run following:
    sdbinst –u mshtml_shim32.sdb

    On 64 bit OS run following:
    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.

  • Assessing risk for the December 2012 security updates

    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.

    Bulletin Most likely attack vector Max Bulletin Severity Max XI Likely first 30 days impact Platform mitigations and key notes
    MS12-077

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Internet Explorer versions 6, 7, 8 offered this update only to block a defense-in-depth attack vector whereby an attacker could convince a victim to trigger a XSS vulnerability by copy-pasting JavaScript into the URL field.
    MS12-079

    (Word)

    Victim opens a malicious RTF file attachment or previews a rich text email in the Outlook preview pane with Word set as default viewer, resulting in potential code execution in the context of the logged-on user. Critical 1 Likely to see reliable exploits developed within next 30 days. Reading email in plaintext mitigates the potential Outlook Preview Pane attack vector.
    MS12-081

    (Windows File Handling)

    Victim navigates to a malicious WebDAV or SMB share and encounters a maliciously-crafted Unicode filename. Critical 1 Likely to see reliable exploits developed within next 30 days.  
    MS12-078

    (Windows font drivers - ATMFD & win32k.sys)

    Most likely attack vector is an attacker who is already running code on a machine leverages vulnerability to elevate from low-privileged account to SYSTEM. Critical 1 Likely to see an exploit released granting a local attacker SYSTEM level access. One of the two CVE’s usable for denial-of-service only. The other (CVE-2012-4786) could potentially be embedded in either an Office document or a PDF file.
    MS12-080

    (Oracle Outside In for Exchange)

    Attacker sends email with malicious attachment and lures victim to view the attachment as a webpage within Outlook Web Access. The attacker could potentially compromise the server-side process generating the web page. Critical 1 Likely to see reliable exploits developed within next 30 days. Oracle Outside In process runs at a lower privilege level, LocalService. For more background information, please see this SRD blog post.
    MS12-082

    (DirectPlay)

    Victim opens a malicious Office document having an embedded ActiveX control, resulting in potential code execution in the context of the logged-in user. Important Will be difficult to build a reliable exploit for this vulnerability. Less likely to see consistently working exploit code in the next 30 days.  
    MS12-083

    (IP-HTTPS Security Feature Bypass)

    Attacker having a legitimately issued but hence revoked computer certificate able to establish a DirectAccess tunnel to gain access to a corporate Intranet. Important N/A Not Applicable - Security Feature bypass only with no direct code execution potential. This attack is only possible after attacker obtains a revoked computer certificate that is trusted by the IP-HTTPS server.

    - Jonathan Ness, MSRC Engineering

  • MS12-083: Addressing a missing certificate revocation check in IP-HTTPS

    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