28

I've just read this question What is the corrupted image vulnerability? How does it work? (GIFAR, EXIF data with javascript, etc..)

I'm asking myself how can I protect myself and my website's users.

My users are allowed to upload their own images (e.g. forum avatars, pictures as part of a message), these pictures being displayed to all other visitors of the corresponding page.

What can I do to be sure that an uploaded file is a real, plain picture and not something else? I'm not asking about a way to overcome specific vulnerability, I'm asking how can I be sure that file contain nothing else than a plain image data? (so I'll probably be protected also against 'yet to be find' vulnerabilities)

xun
  • 383
  • 1
  • 3
  • 6
  • 1
    worth also having a read of http://security.stackexchange.com/q/8113/485 – Rory Alsop Nov 02 '11 at 08:51
  • Isn't it a dupe of [What steps should be taken to validate user uploaded images within an application?](http://security.stackexchange.com/questions/235/what-steps-should-be-taken-to-validate-user-uploaded-images-within-an-applicatio) with the best, IMO, answer there ["You would definitely need to rewrite the image"](http://security.stackexchange.com/questions/235/what-steps-should-be-taken-to-validate-user-uploaded-images-within-an-applicatio/3016#3016) still, IMO, being the best one here – Gennady Vanin Геннадий Ванин Nov 03 '11 at 12:48

3 Answers3

24

I have some suggestions:

  1. Use a separate domain. Host the images on a separate domain that is used only to host user-provided images.

    This will ensure that many browser-level attacks can have only limited effects. For instance, suppose the user's browser is vulnerable to content-type sniffing attacks, so it is possible to upload an image that some browsers will treat as HTML containing malicious Javascript; this defense ensures that the malicious Javascript can only tamper with other user's images, and cannot access your site's cookies or content or other security-sensitive stuff. However, this does not defend against code-injection attacks that exploit a vulnerability (e.g., a buffer overrun, a double-free) and execute native code.

  2. Defend against content-type sniffing. Follow practices I've outlined elsewhere to defend against content-type sniffing attacks. The most important one is to set a correct Content-Type: header on the HTTP responses where you serve the image. It can also be helpful to include a X-Content-Type-Options: nosniff header, to prevent some versions of IE from trying to do content-type sniffing.

  3. Convert to a fixed format. Convert the input image to a bitmap (keeping only the bitmap data, and throwing away all the extra annotations), then convert the bitmap to your desired output format. One reasonable way to do this is to convert to PBM format, then convert to PNG.

    This is not a reliable way to stop attacks, but it reduces some of the attack surface available to the attacker. For instance, it prevents the attacker from attaching malicious metadata that are crafted to exploit some vulnerability in the image parser. It also does not give the attacker a choice of image formats. To defeat this defense, the attacker must find a vulnerability in the PNG decoder, in the code that reads image pixel data. It prevents the attacker from exploiting a vulnerability in the decoder for some other image format or in the part of the PNG parser that reads metadata. So, while potentially helpful at reducing the risk, I would not expect this defense alone to be sufficient.

  4. Consider randomization. Consider inserting some random noise into the image. For instance, you might loop over all the pixels, and for each of the three intensities (corresponding to RGB) for that pixel, randomly choose among adding 1, subtracting 1, or leaving that intensity value alone. This introduces a tiny bit of noise into the image, but hopefully not enough to be noticeable to viewers. And, if you are lucky, it may make some attacks less likely to succeed, because the attacker cannot fully predict the result of the transformation. This defense is highly heuristic and is certainly not guaranteed to be effective, but it is possible it might help, if used in addition with the other defenses I've outlined, as a sort of belt-and-suspenders defense-in-depth strategy. But please understand that this defense alone is probably not adequate.

Depending upon how concerned you are about these risks and the sensitivity of your site, you don't need to do all four. If you are not concerned about code-injection vulnerabilities in the browser, you could do just #1 and #2. If you want partial protection against code-injection vulnerabilities in the browser, you could do just #1, #2, and #3.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • @D.W. What do you mean when you say randomization defense is "highly heuristic"? – Pacerier Jul 13 '12 at 02:40
  • 1
    @Pacerier, yeah, that was crummy wording. I guess you could remove "highly heuristic" from my answer without detracting from my meaning. Basically, the randomization defense is not well-vetted and not grounded in any kind of solid scientific foundation, so don't blame me if it turns out to be useless. :-) Caricaturing, we could imagine two kinds of defenses: Fort-Knox security (we have a strong reason to believe this provides solid protection), and duct-tape approaches (hey, if all goes well, it might help, but don't sue me if it turns out to be worthless). This is of the latter variety. – D.W. Jul 13 '12 at 18:13
7

One possible solution would be to re-write the file as a simple known format before displaying the image on the site. e.g. someone upload an image (possibly with an exploit), immediately, the server read the image in a secure way and write a new image. If the program/script that used to read the uploaded image read only color data, the new image can only contain color data.

dvb
  • 229
  • 1
  • 3
  • 4
    This is really the only practical way to deal with image uploads. The only issue is reading the file "in a secure way" - it's not hard to create compression bombs leading to a DOS. – symcbean Nov 02 '11 at 11:35
  • I don't agree with this answer. For all you know, maybe the attacker can find an input image such that, when it is fed through this transformation, the result is the malicious GIFAR (or whatever) with the exploit. I don't know of any rational basis for believing that this is impossible: or at least, I believe one would need to impose some additional restrictions beyond those mentioned by dvb. – D.W. Nov 03 '11 at 05:24
  • As far as I remember, GIFAR alone is not dangerous, as the attack also need to inject custom html into a page to load the JAR/GIF. – Dog eat cat world Nov 03 '11 at 07:46
  • 1
    @Dog eat cat world, my answer has nothing to do with GIFAR. Suppose that there is some malicious image *I* that is dangerous and that would be unsafe, if it were to appear on the site. dvb seems to be assuming that by applying some transformation *T*, we can be sure that image *I* will never appear; we'll only see *T(I)*. However, I find that assumption dubious. What if the attacker is able to find another image *H*, such that *T(H)* = *I*? Then the attacker could submit *H* as his image; after the server applies the transformation, it will now start serving the dangerous image *I*. – D.W. Nov 03 '11 at 18:29
  • @symcbean Whats a compression bomb, and when would it happen? – makerofthings7 Feb 21 '12 at 19:33
  • @makerofthings7: http://en.wikipedia.org/wiki/Zip_bomb – symcbean Feb 29 '12 at 09:41
4

I guess it depends on perspective? From the end-user standpoint, to protect against exploits (esp memory/buffer overflows) from images or any other source (again, that exploits buffer overflow vulnerabilities) would benefit from making sure memory protection features are fully enabled. In Windows, mechanisms like DEP (based on NX/XD) and ASLR among others are utilized to reduce the likelihood of code execution due to a buffer overrun. DEP can be turned on by default for all applications rather than just opt-in, for eg.

This is in addition to the usual suggestions of using antivirus, keeping software patched, and the other obvious stuff.

If you have an option to sandbox your applications to limit damage (post-exploit), then that is a viable avenue as well. At the very least, you can utlize the principle of least privilege (for eg, by not using administrative accounts where not needed).

Hope that helps.

Garrett
  • 324
  • 1
  • 4