Ways to stop people from uploading GIFs with injections in them?

Question

I have a PHP website where people can fill out help-tickets. It allows them to upload screenshots for their ticket. I allow gif, psd, bmp, jpg, png, tif to be uploaded. Upon

Answer 1

I dont know much about image formats, but recreating the images and then storing the result, I feel has a good chance of eliminating unnecessary tricky stuff. Especially if you strip all the meta data like comments and all the other types of optional embedded fields that some image formats support.

Answer 2

1) You're never going to know exactly what the problem was if you deleted the .gif and your A/V didn't write a log.

Q: Is the .gif in question still on the server?

Q: Have you checked your A/V logs?

2) There are many different possible exploits, which may or may not have anything directly to do with the .gif file format. Here is one example:

• http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-images.html

3) To mitigate the risk in this example, you should:

a) Only upload files (any files) to a secure directory on the server

b) Only serve files with specific suffixes (.gif, .png, etc)

c) Be extremely paranoid about anything that's uploaded to your site (especially if you then allow other people to download it from your site!)

Answer 3

You can use the getimagesize() function for this. If the image is invalid it will simply return false.

if (getimagesize($filename)) {
    // valid image
} else {
    // not a valid image
}

It's worth noting that this isn't 100% safe either, but it's the best you can do as far as I know.

Read more about this here.

Answer 4

You can try phpMussel on any php script that accepts uploads. The file will be scanned using ClamAV signatures, plus some internal heuristic signatures that look for this type of intrusion specifically.

Answer 5

As for the first question, you'll never really know if you're not able to retrieve any logs or the images in question, because there are many things these exploit may have targeted and depending on what's the target the way the exploit was put into the file can be completely different.

Edit: W32/Graftor is a generic name for programs that appear to have trojan-like characteristics.

After opening the file 5060.gif in a hex editor, I noticed the program is actually a renamed windows program. Although it's not a browser exploit and thus harmless unless it's actually opened and executed, you'll have to make sure it isn't served with the MIME type defined by the uploader because a user may still be tricked into opening the program; see the answer to the second question.

As for the second question: to prevent any exploit code from being run or a user, you'll have to make sure all files are stored with a safe extension in the filename so they are served with the correct MIME type. For example, you can use this regular expression to check the file name:

if(!preg_match ( '/\\.(gif|p(sd|ng)|tiff?|jpg)$/' , $fileName)){
    header("415 Unsupported Media Type");
    die("File type not allowed.");
}

Also make sure you're serving the files with the correct Content Type; make sure you don't use the content type specified with the uploaded file when serving the file to the user. If you rely on the Content-Type specified by the uploader, the file may be served as text/html or anything similar and will be parsed by the users' browser as such.

Please note that this only protects against malicious files exploiting vulnerabilities in the users' browser, the image parser excluded.

If you're trying to prevent exploits against the server you'll have to make sure that you won't let the PHP parser execute the contents of the image and that the image library you are using to process the image does not have any known vulnerabilities.

Also note that this code does not defend you against images that contain an exploit for the image parser used by the users browser; to defend against this, you can check if getimagesize() evaluates to true as suggested by Jeroen.

Note that using getimagesize() alone isn't sufficient if you don't check file names and make sure files are served with the correct Content-Type header, because completely valid images can have HTML / PHP code embedded inside comments.

Answer 6

Late response, but may be useful for somebody. You may try such approach:

//saves filtered $image to specified $path
function save($image,$path,$mime) {
    switch($mime) {
        case "image/jpeg"   : return imagejpeg(imagecreatefromjpeg($image),$path);
        case "image/gif"    : return imagegif(imagecreatefromgif($image),$path);
        case "image/png"    : return imagepng(imagecreatefrompng($image),$path);
    }
    return false;
};