Today, we revised Security Advisory 2757760 with two new pieces of information:
- A Fix It solution is available to address the vulnerability via an app-compat shim
- The comprehensive security update will be released out-of-band on Friday.
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.
Conclusion
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