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:

More information about this FixIt at KB 2501696.

What would be the side-effect of MHTML lockdown workaround?

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.

Step 1: Create the test.mht with the following content:

From: "Test"

Subject:

Date: Mon, 1 Jan 1111 11:11:11 -0800

MIME-Version: 1.0

Content-Type: text/html;

       charset="utf-8"

Content-Transfer-Encoding: quoted-printable

X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543

 

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type>

<SCRIPT>

function foo()

{

alert("hello");

}

</SCRIPT>

 

<META name=3DGENERATOR content=3D"MSHTML 8.00.7600.16700"></HEAD>

<BODY onload=3Dfoo()>test MHTML protocol </BODY></HTML>

Step 2: Upload the test.mht to a web server.

Before applying the workaround, when you navigate to Error! Hyperlink reference not valid., the following screen pops up:

As shown, the script within MHTML content is running.

After applying the workaround and restarting IE, when you navigate to Error! Hyperlink reference not valid., the following screen pops up:

The information bar indicates that the MHTML protocol is locked down so the script is not allowed to run.

- Dave Ross and Chengyun Chu, MSRC Engineering