Internet Explorer Download Zones Mix-up leads to XSS

Do you worry about security when downloading and opening HTML files from the Internet? I've been asking around over the past few days, and most people seem to feel they can rely on IE's My-Computer zone security restrictions to keep safe.

A few days ago, I discovered a security flaw in Internet Explorer that could - under certain conditions - be exploited against a large number of web-applications. The flaw results in XSS holes in websites that allow the downloading of user-controlled HTML files (for example, webmail and forum services). The websites themselves don't necessarily do anything wrong. Their susceptibility to attack is due to improper behavior by Internet Explorer.

Same Origin Policy is supposed to ensure that once HTML is downloaded to the user's machine and opened locally, it can no longer access, or pose a threat to the source website – as it is no longer affiliated with that website's domain. Relying on browsers to apply this policy, websites frequently allow users to download original, unaltered versions of attachments, to their local-systems. Usually that's fine, but it seems that there is a download scenario in IE that does not follow this guideline.

It turns out that if you download an HTML file via IE and click the "Open" button in the "File Download" dialog (a fairly common scenario), instead of IE displaying the content from the local hard-drive (in the My-Computer Security Zone, which is very restrictive by default) the HTML is displayed in the context of the domain from which the file was downloaded. This behavior is neither expected nor desired.

If the downloaded HTML file contains a malicious JavaScript code, it will automatically be executed by Internet Explorer in the context of the original website. The risks this problematic behavior poses to IE users are equivalent to those of XSS. Since the problem lies with Internet Explorer and not any specific website, the risk to users is widespread. In effect it makes a large amount of websites susceptible to XSS to some extent.
In order to better describe the problem, let's consider the case of webmail services. Most webmail services offer a preview feature that allows the user to view an HTML version of attachments. The generated HTML is scanned and sanitized in order to ensure that it doesn't contain hazardous characters when embedded within the site.

The same principle is applied to HTML attachments. When they are viewed in the context of the web-application, all potentially harmful content (such as scripts) is stripped. While these measures protect users from security threats such as XSS, the design and functionality of the HTML attachment file might be damaged as a result, and for this reason webmail services offer a "Download" feature that lets the user download the original content of the attachment. Surfers can – and frequently do – use the "Download" feature when the sanitized version of the attachment is not satisfactory. This fact might be taken advantage of by a malicious attacker trying to exploit the aforementioned flaw.

While people are already educated to be suspicious of opening executable attachments, most people (and perhaps technical people in particular) are likely to open HTML attachments rather freely. HTML attachments are perceived as being with very small risk thanks to the My-Computer Zone protection mechanisms embedded in Internet Explorer. I therefore believe that despite the generic warning displayed in IE's "File Download" dialog (see "Flow of attack" section below), IE's improper behavior could be used by malicious attackers to mount attacks against visitors in a variety of web applications.

Microsoft was notified about the problem, but decided to not flag it as a security threat that has to be fixed, relying on the general warning message embedded in the "File Download" dialog.

For the reasons I described above, I believe it is important to warn users about this flaw, in order to help to mitigate the risk it poses to potential victims.

A brief review of several popular web-applications (forum infrastructures and webmail services) has shown that the flaw described above is fully exploitable in many of them. Until this flaw is fixed, IE users are potential victims when visiting and downloading attachments in web-applications of this type.

Vulnerable web-applications can protect their users by ensuring that the domain from which files are downloaded is different to that used by the code logic of the application itself. However, since this change isn't trivial, it's likely that many websites will remain vulnerable in the near future.

I therefore recommend thinking twice before opening HTML attachments with the "Open" button in Internet Explorer.

Flow of attack:

1. Victim receives an HTML attachment and decides to download it in order to watch it properly.
2. Victim clicks on the "Open" button.
    
3. The HTML is displayed by Internet Explorer in the context of the source website. JavaScript embedded in the downloaded HTML file has full access to the resources of the source website, and can fully impersonate the victim on the source website while she/he is calmly viewing the supposedly innocent HTML attachment.
   

Comments

[Mark]

Wow! Great job, Yair!

[Rafel Ivgi]

I agree that with the concept that it shouldn't run in the context of the domain, but in practice this not a security vulnerability because when an HTML file is downloaded to be opened locally, it can then READ AND POST ANY LOCAL FILE ON THE COMPUTER, INCLUDING THE COOKIES DIRECTORY, also its really easy to execute code ;) [if you wanna buy :)] so the least of the problems are a script running in the context of the webmail.

[ory segal]

Hi Rafel,

I think the text is a bit unclear, but the file does not open in the My-Computer zone, but rather in the context of the domain it came from.

[Yair Amit]

Hello Rafel,

Thank you for your comment. :)

As far as I know, Internet Explorer uses two protection mechanisms (which are activated based on the usage scenario of the user) in My Computer Zone.

The first one is total blockage of JavaScript and ActiveX unless the user gives direct consent to it (the well-known yellow security bar).

The second one is activated when the user saves the HTML file via IE and then opens it. The HTML is viewed with JavaScript enabled but in a sandboxed environment that is supposed to disallow ActiveX and to limit XMLHttpRequest object permissions.

Are you aware to ways to circumvent the aforementioned security measures?

[Rafel Ivgi]

I am aware of the fact that when the file is saved from the download prompt IE, only in XP SP2, an NTFS ADS(Alternate Data Stream)called "Zone.Identifier" is created and it is checked when the file is opened. This causes the file to be opened in Internet Zone. I got your point that this can cause XSS within the domain, but i believe that with a few redirect bugs, saving an html can lead to code execution.

[vicente]

holasss muchoss tankiusss