Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

How would you analyze an image to find out if there are scripts or possible malware embedded in it? What tools / methods to use?

share|improve this question
    
nice question, I hope someone answer that. how to implement it in PHP... –  Sheriff Dec 27 '11 at 9:36

4 Answers 4

In order to prevent Internet Explorer >=8 from MIME-sniffing a response away from the declared content-type, you could add the X-Content-Type-Options header with the value nosniff. See http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx

share|improve this answer

In addition to @bobince's answer, you should also watch out for scripts embedded in image metadata. This is a risk if you are displaying, for example, EXIF data from user-submitted images. (I found a couple of XSS vulnerabilities in a popular image gallery based on this method of injection.)

Many tools/libraries will show you image metadata. Exiv2 is a handy tool for viewing and manipulating EXIF and IPTC image metadata.

share|improve this answer

I am assuming that you're going to be accepting user-uploaded image files and serving them to other users through a web application. In that case there are two different attack vectors here.

(1) files that can be interpreted as both image and another type.

This includes:

(1a) files with embedded HTML tags, which can then be loaded as HTML by a browser that does content-sniffing, and scripting content inside executed in your domain's security context, causing traditional JavaScript XSS.

(1b) files that can be interpreted as plug-in data, most notably Java (GIFAR attack). Just hosting these can get you compromised for XSS because the Same Origin Policy in Java and Flash is based on the location hosting the file, not the including page.

Such files can commonly be valid images of the expected type as well as working as the vulnerable target type.

You can make these attacks difficult by processing submitted images, loading them in and re-saving them. You may be doing this anyway in order to do cropping, resizing or quality-level changes.

It is in principle possible for someone to submit an image that, when compressed by whatever algorithm you're using, pops out an image with <script> or other bad content in, but this is probably quite impractical in reality.

Either way, you should mitigate this attack by serving any user-submitted files from a separate domain that does not have the ability to script or share cookies with the main website domain. (It can be a subdomain as long as there is nothing served on any shared ancestor domain.)

(2) malformed images that exploit bugs in browser image decoders to cause arbitrary code execution. These aren't common today but there have been image decoder bugs in the past and it is possible some more may arise.

This can also be defeated by loading and re-saving the image; even just not getting an error on load is generally a good sign. However, it is conceivable that there could be a bug in your own image decoder, which would then make your server-side vulnerable to exactly the same problems.

So make sure your server-side image processing components up-to-date, and, where you can, limit the number of accepted input formats in order to reduce the attack surface. You may also wish to consider running the image handling in a lower-privilege process (privsep) if this is a likely threat for your app.

Loading an image for processing also carries the risk of server-side denial of service attack through very large images (in size and/or compression bombs). Sanity-check the file size and resolution from image file header before attempting to load.

Depending on what your app is, there may be limited benefit from detecting malformed-image exploits because (apart from their rarity) it's usually easy for an attacker to host them elsewhere and post the image or a link to it in other user-submitted content.

share|improve this answer
    
I wish that assumption was correct. The reason I am asking is because every so often particular screenshots end up on my clipboard. I have not been able to duplicate it, but one time I accidently pasted the image in a text box and it looked like encrypted text. I am trying to figure out how to reverse engineer these images and find out what is happening, whether malware or accidental shortcut. :) Thanks for your very knowledgeable answer, it will surely come in handy. –  m4ck Dec 27 '11 at 13:57
    
@m4ck: That's odd, I can't paste an image into a text box, on Windows or Linux at least—what environment are you using? Can you paste them into a text editor to get an easier look at them or save them? HTML-in-image attacks and archive-in-image attacks should be easily detectable from visual inspection; spotting rootcode inside would be considerably more difficult. –  bobince Dec 27 '11 at 18:38
    
Does "X-Content-Type-Options: nosniff" fully protects from (1a), i.e. from XSS through shown images? –  Andrey Botalov May 11 '12 at 18:31
    
@Andrey: yes, but only for browsers that support it: currently IE8+, Chrome11+. It's definitely worth doing, but it doesn't cover enough to work as a security measure yet. –  bobince May 15 '12 at 11:43

Most virus scanners use a signature based detection can find out embedded malware in any files.

However, those malwares are rarely executed if it is a real image (file extension) the image is displayed using a correct program, who does not try to "execute" an image.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.