IE's MIME Sniffing Allows Execution of Images

http://www.heise-online.co.uk/security/Risky-MIME-sniffing-in-Internet-Explorer--/features/112589

by durin42 • 17 years ago

18 5 17 years ago

heise-online.co.uk

CalmQuiet• 17 years ago

I avoid IE almost entirely, so I don't know enough to evaluate his proposed solutions/safeguards, but I'd sure appreciate some evaluation of his proposed protections from someone who does so that I can advise clients about self-protection.

Especially I'd like some help regarding his suggestion that one set IE so that "Open files based on their content and not the filename extension". But he then hedges his bets by saying, "However, that could reopen some old holes!" It seems a weak solution merely to await the "better": "better if web service operators took security precautions".

What prophylaxis do Hackers that use IE plan to employ, if any?

ratsbane2• 17 years ago

I avoid IE too, but about 52% (and shrinking) visitors to sites I work with still do use IE so we still have to deal with it.

This is the first article I've read about this problem (thanks, HN.) Here's a quick summary of what I think I need to do about it: (corrections appreciated)

1) For any situations where you allow users to upload files which may be sent back to the browser as images, run some kind of check to ensure it's a valid image, e.g. ImageMagick "convert"

2) ensure you return content-type headers with the correct image type.

durin42• 17 years ago

In the case of sites that refer to user-specified images by just linking to the image (as with some forum software, at least a couple of years ago last I used such things), they need to change behavior, otherwise the upstream site can change content-type and content at the URL after validation and perform XSS on anyone that ends up seeing the "image."

I could be wrong about that, someone please correct me if so.

tptacek• 17 years ago

This problem is nothin'. You want a real problem in this vein? Check out Nate McFeters' GIFAR attack. The long/short of it:

GIF's have headers. Java JAR files, being ZIP archives, have trailers. To read a GIF, the image rendering code readers a header off the beginning of the file. To read a JAR, the unzip code seeks to the end of the file. It is therefore possible to have a perfectly valid, displayable GIF image that is simultaneously a perfectly valid, executable JAR file. Go ahead and upload it to your web app.

Why is this a problem? Because the Same Origin policy for Java applets is fucked up. Java applets have affinity for the site that delivered the bits for the applet itself; if you upload a GIFAR to Flickr, and Flickr doesn't catch it, you've now hosted a Java applet on Flickr that has Same Origin affinity to Flickr. Compose an "<object>" tag somewhere else on the Internet (pref. MySpace) and you've owned up the Flickr session for anyone who trips over it.

But wait! There's more! The Same Origin affinity for a GIFAR stored locally --- locally? how? an exercise for the reader! --- is localhost! A GIFAR that lands on your hard drive can, driven from an "<object>" tag anywhere on the Internet, make arbitrary TCP connections to services on your own host. Did you password your MySQL server?

Browsers are far and away the most difficult pieces of software we have to secure.

IE's MIME Sniffing Allows Execution of Images

Related Stories