January, 2011

At Microsoft, as at most large software vendors, we are likely to have publicly known issues under investigation at any given time. This is what we do on the Security Research & Defense team. Recently we’ve seen confusion from folks trying to make sense of some of the current public issues. To help clear that up, we offer this table of information to help customers make a risk assessment for their particular environment. Note that applying the Microsoft-recommended workaround for any issue in the table removes the risk posed by the issue entirely.

Proof-of-concept code we have seen so far requires a user to browse to an attacker-writable folder using Windows Explorer. If Explorer is set to display thumbnails or a preview of contained files (neither setting is the default), the chance of code execution exists. Current proof-of-concept code is not successful when Explorer is set to display files in the default List mode.

As listed in Security Advisory #2490606, modify the Access Control List on shimgvw.dll. The advisory also lists a one-click FixIt to automate this configuration change.

IIS 7.0 and 7.5 FTP service vulnerability in encoding Telnet IAC (Interpret As Command) characters in the FTP response.

A fuzzer for various browsers was released, as well as information on a crash that shows a potentially exploitable condition. While the fuzzer is successful in encountering exploitable memory corruption issues in Internet Explorer, we have been unable so far to turn a crash into a stand-alone HTML page that could be used as a browse-and-own exploit. Encountering the issues appears dependent on first loading many previous iterations of HTML in the fuzzer, making the issues we have discovered so far less useful for the purpose of real-world attacks. We are still investigating this issue and will monitor for any developments that may change the current risk.

Unable to make an assessment at this time without stand-alone PoC. However, we are working on a security update to address the issues found in fuzzing.

WMI Administrative Tools ActiveX control vulnerability.

Only the very few customers who have installed the WMI Administrative Toolkit are vulnerable to this issue. This product has a small number of total downloads. The ActiveX control itself is not signed by Microsoft. This is not a case where an attacker can host a Microsoft-signed ActiveX control and entice the user to make one click to allow it to install.

The real-world risk to most customers from this issue is expected to be quite low.

This ActiveX control can be killbitted to protect any machines that have installed the WMI Administrative Toolkit. The affected ActiveX control was not intended to be instantiated within Internet Explorer so legitimate use of the WMI Administrative Toolkit should not be impacted by this configuration change.

The attached .txt file, if renamed to .reg and opened, will apply the killbit to the affected clsid’s.

We hope that this helps customers make a risk assessment for your environment. We are closely monitoring each of these issues, and we will update or issue advisories if the threat landscape changes.

Thanks to each of the case managers and security engineers who worked over the holidays to respond appropriately to these public disclosures!

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

We have just updated Security Advisory 2488013 for the publicly-disclosed Internet Explorer CSS vulnerability. It now reflects the fact that limited attacks attempting to exploit this vulnerability are present in-the-wild. The advisory also includes a new workaround that can help protect your computers until a security update is available. This workaround is different from the workarounds that we typically recommend, and so we wanted to give you more detail about it here.

Vulnerability Recap

This vulnerability requires an attacker to provide a CSS style sheet that includes a reference to itself with an @import command. When Internet Explorer tries to load this recursive style sheet, it corrupts memory in a way that could be exploited for arbitrary code execution. Unfortunately, there is no way to selectively disable this functionality, which is why the best workaround up to this point is to enable EMET to block aspects of the known exploits from being successful.

The new workaround

This workaround is an MSI package (Microsoft "FixIt") that uses the Windows application compatibility toolkit to make a small change to MSHTML.DLL every time it is loaded by Internet Explorer. This change causes Internet Explorer to refuse to import a CSS style sheet if it has the same URL as the CSS style sheet from which it is being loaded. Simply put, the workaround inserts a check to see if a style sheet is about to be loaded recursively, and if it so, it aborts the load of the style sheet. You can read more about the Windows infrastructure that allows this type of workaround here: http://technet.microsoft.com/en-us/library/cc748912(WS.10).aspx

Internet Explorer represents CSS style sheets with an instance of the mshtml!CStyleSheet class. The CStylesheet Create() method is called on every style sheet import and has access to the URL of both the parent and child style sheets. To get the absolute URL of the child style sheet, it calls the function ExpandUrlWithBaseUrl, as in the following assembly and graphic:

The workaround replaces this function call with a call to a new function the workaround introduces. This new function does the following things:

Calls ExpandUrlWithBaseUrl() to translate the relative URL to an absolute URL, just like the original code

If ExpandUrlWithBaseUrl() returns an error, then the new function returns that error to CStyleSheet::Create()

It ExpandUrlWithBaseUrl() succeeds, it then calls _wcsicmp() to see if the child’s absolute URL is equal to the parent’s absolute URL

If they are equal, it returns 80004005h, which is an error code ExpandUrlWithBaseUrl() can return if it is unable to do the URL expansion

If they are not equal, it returns 0, mimicking a successful ExpandUrlWithBaseUrl() call that CStyleSheet::Create() would have made

Now you may ask, where is this new function implemented? The workaround overwrites a function which is only used on process shut down to clean up debugging resources. It changes the first instruction to a ret, so normal calls to this function will simply return, and then implements the workaround check. Here’s a graphic representing the new flow:

What the workaround changes look like

After the workaround is applied, the relevant part of CStyleSheet::Create() is updated to:

The workaround does all of the following checks before modifying MSHTML.DLL:

File version of MSHTML.DLL is as expected

Checksum of MSHTML.DLL is as expected

All of the assembly instructions that will be replaced are exactly as expected

This ensures that it is not applied to the wrong version of MSHTML.DLL and that the results of the change are what were intended by the workaround. If a certain MSHTML.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 to address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. In our testing, we found that it added approximately 150ms to the process start time. Therefore, as you are applying the final security update, you should uninstall the workaround as it will no longer be needed. We also recommend that you test this workaround 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.

What about CSS style sheet loops?

During our investigation, the question came up: what about A.css importing B.css which then imports A.css? In other words, would a CSS style sheet loop trigger the vulnerability too? Fortunately, through testing and code review we’ve determined that this configuration of CSS style sheets will not trigger the vulnerability, so simply checking that the child style sheet has a different absolute URL from the parent style sheet is sufficient to detect and block attacks.

Acknowledgements

Special thanks to Bruce Dang, Jonathan Ness, and Matt Miller for their work on this workaround. Thanks to Robert Hensing for his championing of this type of workaround starting in 2009. (/wave Rob)

- Kevin Brown, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Today we released Security Advisory 2501696 to alert customers to a publicly disclosed vulnerability in the MHTML protocol handler. This vulnerability could allow attackers to construct malicious links pointing to HTML documents that, when clicked, would render the targeted document and reflected script in the security context of the user and target location. The end result of this type of vulnerability is script encoded within the link executed in the context of the target document or target web site.

How could I know if my machine is affected?

By default, the MHTML protocol handler is vulnerable on Windows XP and all later supported Windows versions. Internet Explorer is an attack vector, but because this is a Windows vulnerability, the version of IE is not relevant.

How could I protect client systems?

The security advisory lists steps to lock down the MHTML protocol handler for either all Internet Zone scenarios or to disable it altogether. We have previously blogged about the Network Protocol Lockdown workaround here. You can also click the button below to enable the Network Protocol Lockdown for mhtml: for all security zones:

In our testing, the only side effect we have encountered is script execution and ActiveX being disabled within MHT documents. We expect that in most environments this will have limited impact. While MHTML is an important component of Windows, it is rarely used via mhtml: hyperlinks. Most often, MHTML is used behind the scenes, and those scenarios would not be impacted by the network protocol lockdown. In fact, if there is no script content in the MHT file, the MHT file would be displayed normally without any issue. Finally, for legitimate MHT files with script content that you would like to be rendered in IE, users can click the information bar and select “Allow All Protocols”, as shown below.

Doing so would temporarily allow the script content in the MHT file, and thus keep MHT files rendered correctly. Please note here that selecting “Allow All Protocols” will not undo the MHTML workaround permanently.

How can I know whether my service is at risk?

Any service that allows user input to be reflected back to the user could be affected by this issue. However the impact of scripting injected into a service is dependent on how the service itself is implemented. In this way, the impact is the same a server-side cross-site scripting issue but the vulnerability lies in the client.

What actions could service provider owners take?

First, please recommend that your customers apply the client-side workaround in the Security Advisory. This will prevent customers from being affected no matter how an attacker chooses to craft the link.

There are potential server-side workarounds that a service owner could employ. We’re working with service providers like Google and others as we explore these options. Some of these ideas are listed below. Each of these approaches is worth exploring and we continue to do so. However, they may be difficult for websites to implement comprehensively. For example, while newline filtering might be introduced in certain scenarios, low-level HTTP error response pages could reflect data in a way that is difficult to identify and mitigate. Each of the ideas are intended to break the parsing of MIME content and include:

Filtering newline characters out of requests/responses

Prepending newline characters onto an HTTP response

Altering the status code on the HTTP response

Additionally, client/server interactions and decoding behavior may mean that in certain configurations these approaches are not fully effective.

We will continue to investigate server-side workarounds, and will continue to update with guidance as more are discovered. However, for the reasons above we recommend using the client-side workaround listed in the advisory, which can block exploits regardless of the service.

How can I test that a client system is protected?

Here are the steps to set up a test to ensure that a machine on which the workaround is enabled is protected from this vulnerability.