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
Today we released MS12-074, addressing a Critical class vulnerability in the .NET Framework that could potentially allow remote code execution with no user interaction. This particular CVE, CVE-2012-4776, could allow an attacker on a local network to host a malicious WPAD PAC file containing script code which could be executed on a victim machine without requiring any type of authentication or user interaction. To help you assess and mitigate the risk this vulnerability poses in your environment, we’d like to explain each of elements of a successful attack and list the potential workarounds and countermeasures.
First, an attacker would need to act as the authoritative proxy auto-configuration file server for your network. One way this could happen is if an attacker is able to register the hostname WPAD on your network. Alternately, an attacker present on your network segment could potentially act as a man-in-the-middle and respond to any WPAD queries for a legitimate proxy auto-configuration file server. Or, an attacker having the ability to spoof DHCP, DNS, or lower layer responses on your network segment can specify an arbitrary proxy auto-configuration file server directly.
The second element necessary for this attack is an outbound request from a .NET application requesting the proxy auto-configuration file server. Simply launching the browser is not enough to trigger this vulnerability. An Internet-based attacker would have trouble triggering this outbound request because the common browser-based Internet Zone .NET application mechanisms have been disabled by default, as of MS11-044. However, if an attacker can lure a victim user to an Intranet Zone site they control, the attacker could potentially instantiate an XBAP-based application which would trigger the request. If a .NET application uses the default proxy settings of the system either implicitly or explicitly via the .NET WebRequest.DefaultWebProxy property, and the app.config default proxy setting is not present, the Internet Explorer proxy settings will be used. If the “Automatically Detect Settings” box (shown below) is checked in Internet Explorer’s Internet Options->Local Area Network (LAN) Settings, the system will use WPAD to try to find the configuration file when the default proxy lookup is requested by the .NET application.
The third element necessary to trigger the vulnerability is the proxy auto-configuration file server responding with a PAC file containing malicious script code. If you are particularly concerned about this attack, you might consider inspecting PAC files for malicious script code.
Workarounds and Countermeasures
Installing the MS12-074 security update will comprehensively address this vulnerability. If you are unable to do so, you might consider other options to protect your machine from being exploited by this .NET vulnerability. The workaround list below is sorted by our recommended order of effectiveness:
1) Explicitly set the proxy in .NET application’s code. This avoids default proxies at the application level. 2) If not 1, provide an app.config file for your .NET app with the proxy explicitly set in it. This avoids default proxies at the application configuration level. 3) If not 1 or 2 (because your .NET app MUST rely on a default proxy), uncheck "Automatically Detect Settings" and instead provide a location in "Use automatic configuration script" in IE Internet Options->Local Area Network (LAN) Settings, as shown above. This avoids WPAD entirely. 4) If not 3, Register WPAD. See http://support.microsoft.com/kb/934864 for details. This protects WPAD from being spoofed.
The proxy configuration file is searched for in a sequence of steps, which can be found at http://blogs.msdn.com/b/askie/archive/2008/12/18/wpad-detection-in-internet-explorer.aspx.
We hope this blog post helped clarify the risk posed by this vulnerability to your network. Please email us with any questions you might have at switech [at] Microsoft [dot] com.
- Neil Sikka, MSRC Engineering
Today we released six security bulletins addressing 19 CVE’s. Four of the bulletins have a maximum severity rating of Critical, one has a maximum severity rating of Important, and one has a maximum severity rating of Moderate. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
(Windows drivers [win32k.sys])
The third (CVE-2012-2897) has a theoretical remote code execution attack vector in that TTF fonts can be embedded in both Office documents and PDF files and are also rendered by third party browsers. However, we have been unable trigger this particular vulnerable code path via any remote attack vectors in our experiments.
(.NET Framework)
(Windows Shell)
(Excel)
(Internet Information Services [IIS])
Info disclosure only. No code execution.
Today we released seven security bulletins addressing 20 CVEs (7 Microsoft and 13 Oracle CVE’s). Only one of the bulletins is rated Critical. The other six 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.
(SafeHTML)
(FAST Search Server for Sharepoint)
(Kerberos)
(Works 9)
(Kernel)
(SQL Reporting Services)
In addition to the seven new security bulletins, we have re-released MS12-043 to make available a security update for Microsoft XML Core Services 4.0 on Windows 8. (MSXML4 does not ship with Windows by default but can be included as a redistributable component with installed applications.)
We are also revising security advisory 2661254 to note that the update is now available for all customers over Automatic Updates.
Finally, we are releasing a new security advisory, 2749655, describing potential compatibility issues due to incorrect digital certificate timestamps in recently-released security updates. You can read more detail about that situation in the security advisory and the SRD blog post.
Please let us know if you have any questions about this month’s release. You can email the MSRC Engineering research team at switech [at] microsoft [dot] com or tune in to the monthly webcast tomorrow at 11 a.m. PDT. Click here to register for the webcast.
Today we released Security Advisory 2749655 to alert customers to a clerical error made in code-signing a number of recently released security updates. This error will cause the digital signature to expire and become invalid prematurely – not a security flaw, but an issue that will impair users’ overall security profile. In this blog post, we’d like to provide more background on the mistake, explain the effect of this error on product functionality, and detail our response to the situation.
What happened?
All Microsoft security updates are code-signed by our Product Release and Security Services (PRSS) team. This central team also manages the code signing and release process for all production Microsoft software. Unfortunately, due to a clerical error, a subset of binaries processed by the PRSS lab between June 12, 2012 and August 14, 2012 were digitally signed in an incorrect manner.
The signing error involved the timestamp placed on each file as it was being signed. The certificate used for timestamping was missing a critical attribute that will cause the digital signature to become invalid at the point in the future when the package’s signing key has expired. Normally, the signing key is valid for a reasonably short amount of time, while the timestamp allows the binary to be trusted as “valid” for a much longer period of time.
Without a properly formed timestamp in place to extend the validity period, these binaries and packages will no longer be trusted as valid as soon as the signing key expires. For some of the affected files and packages, that signing key expiration date falls in the next few months.
Microsoft’s response to the situation
We will re-sign and redistribute all files and packages affected by this issue. Today, we are re-releasing an initial batch of four security updates -- MS12-053, MS12-054, MS12-055, and MS12-058 -- with new digital signatures, each of which has been timestamped with a proper timestamping certificate. We are continuing our investigation and expect to re-release additional bulletins as needed in months to come.
In addition to re-signing and re-distributing the affected files, we are taking an unusual approach to address this issue at the platform layer. The Windows team has created a package with a modified WinVerifyTrust function that makes a special case of the two known timestamping certificates that were missing the critical attribute. This will enable WinVerifyTrust to continue trusting these files and packages while redistribution completes. This WinVerifyTrust package is available as a Critical-class update and will be distributed over Microsoft Update and via Automatic Updates. It is also available on the Download Center directly at (link).
It is important to note that while WinVerifyTrust is the most common place where this check takes place, there are a number of known and potential points where trust may be verified by a third party (such as anti-malware software or software distribution solutions). If the vendor has not made a similar change to their trust model, these files or packages will fail validation. This is why we plan to re-sign and redistribute all files or packages affected by this issue. Again, the older versions of those files and packages are secure and trustworthy just as they are now, but may fail to be recognized as such in later months if they are not updated as soon as possible.
How WinVerifyTrust validates code signing signatures
To put this platform-level change into context (and for those who are not yet familiar with the validation process used by Microsoft products), we’d like to explain the three-step process that WinVerifyTrust uses to validate code-signing signatures. This process is merely a subset of the checks WinVerifyTrust performs, but it should make clear why Security Advisory 2749655 serves an important function.
First, it examines the signing certificate to confirm that it chains to a trusted root. In case of each of these packages, that trusted root is Microsoft. This first step of validation, then, ensures that you can trust that Microsoft signed each of these packages.
Next, WinVerifyTrust ensures that the signing certificate has not been revoked.
Finally, WinVerifyTrust checks that either (A) the certificate is in its validity period, or (B) that it has a timestamp that shows it was signed within its validity period. Because all files and packages signed during this period of time were signed with keys that are still within their validity period, they all pass trust verification. However, when these signing keys start to expire early next year, WinVerifyTrust will start examining the timestamp on these files and packages. With the updated WinVerifyTrust package available today to be downloaded, an option (C) has been added to satisfy this third step of validation. After passing the first two steps of validation, the third step can be satisfied by (A) a signing key still in its validity period, (B) a timestamp that shows it was signed within its validity period, or (C) one of these two specific known timestamping certificates that were missing the critical attribute.
Call to Action
We encourage all customers to apply the re-released, re-signed security updates as they become available. As an additional defense-in-depth measure, we recommend that customers also apply the updated WinVerifyTrust package which serves as an effective way for Windows and Microsoft applications to extend the validity period of these packages beyond the premature expiration date. We should be clear that the re-released, re-signed security updates by themselves are sufficient to address the potential compatibility issue and the WinVerifyTrust package is not strictly necessary - it is offered as a defense-in-depth option to customers who want to ensure that this issue does not affect them between now and the time they apply the updated security updates.
- Dustin Ingalls, Windows and Jonathan Ness, MSRC Engineering
Today, we revised Security Advisory 2757760 with two new pieces of information:
In this blog post, we’d like to explain more about the vulnerability and explain how the Fix It solution addresses the issue. We will also provide more details about the attack landscape and provide our assessment of the effectiveness of EMET against current attacks.
Information about the vulnerability
The vulnerability is a use-after-free issue that exists in the MSHTML module and affects versions 6, 7, 8, and 9 of Internet Explorer. Internet Explorer 10 is not affected. To trigger this type of memory corruption, the exploit invokes the method “execCommand()” to select the content of the web page while assigning a function handler to the event “onselect,” which will delete an object from the memory and try to dereference the freed object immediately after. The inconsistency generated in memory by this behavior may allow an attacker to take control of a function pointer in the VTABLE of the freed object and eventually execute arbitrary code.
Addressing the vulnerability via application compatibility shim
Today we released a Microsoft “Fix it” solution (an MSI package) as a new workaround option. It uses the Windows application compatibility toolkit to make a small change to MSHTML.DLL in memory every time the DLL is loaded by Internet Explorer. It addresses the use-after-free vulnerability by inserting the missing AddRef call within CMshtmlEd!Exec, similar to the actual code fix planned for Friday. You can read more about the Windows infrastructure that enables this type of workaround here: http://technet.microsoft.com/en-us/library/cc748912(WS.10).aspx
It’s important to note that the workaround will protect Internet Explorer only if the latest security updates have been applied. When the next security update affecting MSHTML is applied, the app-compat shim will be automatically deprecated and will no longer make in-memory changes. This is due to the surgical in-memory fix method targeting specific DLL versions. The .SDB file present in the MSI package that installs the app-compat shim database change has a list of DLL versions with specific offsets and assembly instructions for each version of the DLL.
To install the workaround, click here: http://go.microsoft.com/?linkid=9817706
If you’d like to uninstall the workaround after you have installed it, click here: http://go.microsoft.com/?linkid=9817705
Current attack landscape
We have analyzed the targeted attack samples that attempt to exploit this vulnerability. All real attacks we have seen are targeting only 32-bit versions of Internet Explorer and rely on third-party browser plugins to either perform efficient heap-spray in memory and/or to bypass the built-in mitigations of Windows Vista and 7 such as DEP and ASLR. In the current situation, the chances of successful exploitation via the current attacks on Windows Vista and 7 strongly depend on the presence of these plugins on the targeted computers. For example, all exploits relying on the presence of non-ASLR modules shipped by Java6 (as shown in the following code-snippet from a real exploit) can be mitigated by upgrading to the latest version of Java7, or by enforcing ASLR for these modules with EMET or by using the Force ASLR setting.
Using EMET mitigations
We also observed that the Enhanced Mitigation Experience Toolkit offers a good set of additional mitigations for Internet Explorer that can thwart many of the attacks in the wild. Enabling HeapSpray, MandatoryASLR and EAF mitigations for Internet Explorer will make reliable exploitation of this vulnerability more complicated. Users testing EMET 3.5 Tech Preview can use also the new set of mitigations able to break ROP-based exploits, which is also a recommended setting in the current situation.
If you encounter an attack sample for which you believe EMET is not an effective mitigation, please share it with us by emailing it to switech [at] microsoft [dot] com. We would love to take a look to improve the protections the tool offers to all customers.
We encourage you to make a risk decision for your environment and choose to either install the Fix It appcompat-shim based workaround or prepare to deploy the comprehensive security update when it is released on Friday. If you have already deployed EMET in your environment, ensure that the MandatoryASLR mitigation - at least - is enabled for Internet Explorer to raise the bar for attackers by blocking current exploits and introducing an additional cost factor in exploit development.
We will continue to monitor the situation and the evolution of exploit landscape.
Acknowledgements
Thanks to Elias Bachaalany, Cristian Craioveanu, Matt Miller and Suha Can for the hard-work which made possible delivering the Fix it workaround in such short time and for the endless work time spent to keep customers safe.
- Elia Florio, MSRC Engineering
MS-CHAP is the Microsoft version of the Challenge-Handshake Authentication Protocol and is described in RFC2759. A recent presentation by Moxie Marlinspike [1] has revealed a breakthrough which reduces the security of MS-CHAPv2 to a single DES encryption (2^56) regardless of the password length. Today, we published Security Advisory 2743314 with recommendations to mitigate the effects of this issue.
Any potential attack would require a man in the middle situation in which a third party can get all the traffic between the client and authenticator during the authentication.
Without going into much detail about the MS-CHAPv2 protocol, we will just discuss the part that would be affected by this type of attack: the challenge and response authentication. This is how the client responds to the challenge sent by the authenticator:
Or:
C=SHA1(CS,CC,UNAME)P=MD4(PASSWORD)K1|K2|K3=P|5 byte of 0R=DES(K1,C)|DES(K2,C)|DES(K3,C)
There are several issues in this algorithm that combined together can result in the success of this type of attack.
First, all elements of the challenge and response beside the MD4 of the password are sent in clear over the wire or could be easily calculated from items that are sent over the wire. This means that for a man in the middle attacker, the gain of the password hash will be enough to re-authenticate.
Secondly, the key derivation is particularly weak. Padding with 5 bytes of zero means that the last DES key has only a key space of 2^16.
Lastly, the same plaintext is encrypted with K1 and K2, which means a single key search of 2^56 is enough to break both K1 and K2.
Once the attacker has K1, K2 and K3 he has the MD4 of the password which is enough to re-authenticate.
- Ali Rahbar, MSRC Engineering
[1]- https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/