

IE's MIME Sniffing Allows Execution of Images - durin42
http://www.heise-online.co.uk/security/Risky-MIME-sniffing-in-Internet-Explorer--/features/112589

======
tptacek
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.

------
CalmQuiet
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?

~~~
ratsbane
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
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.

~~~
ratsbane
I think you're right. If you embed any image you don't have control over or
allow users to do that then js embedded in the supposed image could gank your
session cookies. Avoidance strategies(?): 1) Copy embedded images to your
server, validate, and substitute link on your server for off-site link 2) To
avoid cross-site scripting hacks anyway, store ip address along with session
key on your server and validate that with every request. (Won't protect
against attackers on the same side of a NAT though.)

This would also affect images embedded in emails, assuming user is using
Outlook or IE to read mails?

