XSS exploit in IE "by design" says Microsoft.

[cooper]

Near the end of April, Tweakers.net developer Tino Zijdel was informed by a visitor that a bug in Internet Explorer 6 as well as 7 allows the execution of a cross site scripting exploit. The problem is with the browser's mime-type detection.

Zijdel informed Microsoft on the 29th of april, demonstrating 2 proof of concepts to the software company. The first example used a valid gif-file, but served to the user with the 'image/jpeg' mimetype. Whenever the extension of a file doesn't match the supplied mime-type, Internet Explorer tries to determine the mime-type on its own, however completely ignoring the GIF signature of the file. Rather than showing an image, the file was treated as HTML code, causing the javascript code in the file to be executed. Since the gif file used in the proof of concept is a completely valid gif file, quite a number of sites that allow the uploading of images can be abused when they use the extension of the filename to determine the mime-type used to serve the file.

In the second proof of concept, a png file with a text-extensionblock is served to the browser. In this block a piece of javascript code is placed as comment. The supplied mime-type is correct, and when the image is referenced in an img tag it gets properly displayed. However when the image is accessed by clicking on a link to it, the HTML and javascript in the file is executed. Zijdel claims both proof of concepts illustrate a violation of RFC2616 as it refers to HTTP/1.1. This RFC states that a browser can only try to guess the mime-type when no Content-Type field is supplied by the server.

Interestingly enough, Microsoft told Zijdel that this behaviour of Internet Explorer is by design, and the company isn't planning to create a patch for these issues. They will however give more attention to the problem when developing the next IE-version. According to an employee of the Microsoft Security Response Center now is not the time to change the behaviour of Internet Explorer because site developers may depend on the functionality that the browser's mime-type detection provides. This however completely ignores the XSS exploit element of the report. When asked about this issue by the Tweakers.net editors the Internet Explorer team maintained that the browser's behaviour is by design.

The first argument given by the IE developers is that IE is supposed to execute scripts when dealing with a file that is both image as well as script. One could counter this argument by stating that a file should be either an image or a script, but never both. The second argument given is even easier to refute. Microsoft claims that using this behaviour it's easier to deal with files that either come without, or with incorrect mime-type. In the case of the png proof of concept however a valid mime-type is provided, and in the case of the gif proof of concept there are a number of reasons to not treat the content as HTML:

• [li]The provided mime-type suggests the presence of binary data.[/li]

[li]The served file is a valid gif image, including the appropriate signature.[/li]

[li]The file contains, next to what could be seen as HTML, also binary data. The content-sniffing mechanism should be able to deduce that the content can't be reasonably displayed as text or HTML.[/li]

Finally Microsoft passes the responsibility on to site-hosters, by recommending them to filter their data based on the contents of files. This however effectively means that websites should start to ban binary data because this data could potentially be 'dangerous' the moment the browser incorrectly handles the mime-type. It should be noted that it's possible to deactivate the mime-type-sniffing-engine, but since it's on by default in Windows XP, Windows 2003 and all systems with Internet Explorer 7, it's fairly safe to assume the majority of systems out there are vulnerable.

Source: http://tweakers.net/nieuws/47643/XSS-explo...-by-design.html

The gif POC: http://tweakers.net/ext/i/1179826281.jpg

The png POC: http://tweakers.net/ext/i/1179826282.png

[digip]

Thats actually pretty cool. Tried it in IE6(after opeing it in a hex editor to see what the script would do)

So, you can change a pages payout on someone using IE6+. I noticed it does not seem to work on Opera, but are there any other browsers that it works on? Anyone try it on another browser to see if they are vulnerable as well?

It would be cool to inject CSS and block all the ads and iframes on a website so they couldn't make revenue from the ads. Sort of usefull in some ways...

EDIT: It would seem the attack only works if the person is sent directly to the image itself. When placed in a web page, the script will not execute. It also will not execute from the desktop, or email.

Example(open in IE6+):

Just the image in http://www.twistedpairrecords.com/testhack.jpg

I have editied the image above to clear the screen of the image data and turn the background red leaving no text from the malformed data if the image.

Now one within a page: http://www.twistedpairrecords.com/testhack.html

The link above has the image placed in the page using normal html. It does not execute, so there is no real threat from this attack unless you redirect someone to the image, which defeats it as an XSS attack, since it can't inject data into the site your viewing or want to target for an xss attack.

[lunex]

There is actually a setting for this exploit. To turn off this exploit open the Internet Options dialog, switch to the Security tab, click Custom Level for the Internet zone, scroll down until you see the option labeled "Open files based on content, not file extension", and disable that option. "file extension" is no doubt a misnomer referring to the Content-Type reported by the http server. This option is for some reason enabled by default in the Internet, Local Intranet, and Trusted Sites zones.

Could anyone create a payload that, when executed, would disable this exploit?