How can I be protected from pictures vulnerabilities?

Question

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)

Answer 1

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.

Answer 2

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.

Answer 3

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.