Yesterday, Microsoft has released Security Advisory 2719615, associated to a vulnerability in Microsoft XML Core Services. We want to share more details about the issue and explain the additional workarounds available to help you protect your computers.
Information about the vulnerability
A vulnerability exists in Microsoft XML Core Services 3.0, 4.0, 5.0, and 6.0 that could be exploited if a user views a specially crafted webpage using Internet Explorer. The issue is triggered when MSXML attempts to access an object in memory that has not been initialized, which may corrupt memory in such a way that an attacker could execute arbitrary code in the context of the logged-on user. This class of vulnerability is exploitable by preparing both stack and heap memory with attacker-controlled data before the invalid pointer dereference.
Which workarounds should you apply?
In a web-based attack scenario, an attacker would have to host a website that contains a specially crafted web page. The vulnerability can be triggered only through the use of Active Scripting, so the following standard workarounds still apply:
- Set Internet and Local intranet security zone settings to “High” to prompt before running ActiveX controls and Active Scripting in these zones.
- Restrict Web sites to only your trusted Web sites.
We consider these, together with disabling MSXML ActiveX controls, to be too disruptive to the Internet Explorer browsing experience to be considered practical for wide adoption. At the same time, we know this vulnerability is actively exploited in the wild for targeted attacks. In such situations, we offer guidance and workarounds in a Security Advisory, in order to protect customers as fully as possibly while we prepare the necessary security update.
In order to assure the safety of our customers during this time, we created a new workaround in the form of a Microsoft “Fix it” package that uses the Windows application compatibility toolkit to make a small change at runtime to either of msxml3.dll , msxml4.dll or msxml6.dll every time Internet Explorer is loaded. This change causes Internet Explorer to initialize the previously uninitialized variable which is at the root of the vulnerability.
You can apply this workaround by running the Microsoft Fix it 50897 from the link below. For enterprise deployment, please refer to Knowledge Base article 2719615, section “Deploying an application compatibility database across multiple computers”.
| Apply | Uninstall |
|---|---|
Microsoft Fix it 50897 |
Microsoft Fix it 50898 |
The workaround does all of the following checks before modifying msxml?.dll in memory (? can be either of 3, 4, 6):
- File version of msxml?.dll is as expected
- Checksum of msxml?.dll is as expected
- All of the patched instructions are exactly as expected
This ensures that it is not applied to the wrong version of msxml?.dll and that the results of the change are what were intended by the workaround. If a certain msxml?.dll does not pass all of these checks, it will not be modified.
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. We believe this workaround would not cause any application compatibility issues, but at the same time recommend that you test it with any internal line-of-business applications before deploying it. The final security update to address this issue will be fully tested and ready for broad deployment.
Note:
You might have noticed that msxml5.dll is not covered by the previous workaround. MSXML5 is not on the pre-approved controls list and should not be used on any web pages. Internet Explorer will pop up the security bar every time a website tries to use it:
EMET
As part of Security Advisory 2719615, we are also recommending EMET as a potential mitigation for possible attacks attempting to exploit this vulnerability. The Enhanced Mitigation Experience Toolkit (EMET) is a utility that helps prevent vulnerabilities in software from successfully being exploited by applying in-box mitigations such as DEP to applications configured in EMET. We recommend to our customers to do a thorough assessment in their test environment before large scale deployment.
Kudos
Shout to Fermin Serna and the Google Security Team for sharing their findings with us; to Qihoo 360 Security Center for reporting the vulnerability. Also thanks go to Bruce Dang, Elia Florio, and Matt Miller for their tireless advice.
- Cristian Craioveanu, MSRC Engineering