tags:

views:

145

answers:

5
+3  Q: 

Security issue?

Hi guys, I am writing a small PHP application and I am not sure whether I have a security issue. So this is what the application does:

  • the user can upload either image files (png, gif, jpg, jpeg, tiff and a few others) or zip files

I check for mime-type and extension and if it's not an allowed I don't allow the upload (this is not the part I am worried about).

Now once uploaded I rename the file to a unique hash and store in a folder outside root access.

The user can now access the file through a short URL. I make the file accessible by setting the right mime-type for the header and then I just use readfile().

My question is whether the exploit where a jar file is included inside the image file works here? I am serving the image as a pure image.

If it does what are ways to prevent this?

Thanks.

+1  A: 

Checking the mime-type is not sufficient because that (or any other) HTTP header field can be forged. The best way to confirm that a file is a valid image is to attempt to read it as an image programatically. If it can be parsed as an image, you can be reasonably confident that it's not malicious code.

Asaph
Would the downvoters care to leave a comment?
Asaph
The jar exploit actually makes a real image the validates in any image viewer.
Byron Whitlock
In that case, resize the image (which you may end up doing anyway) and you'll be reasonably safe.
Asaph
I can't resize the image. I need it as an original. Is this actually an issue if i later try to output the file as an image? i am not giving any liberties on how to view the image...
mistero
Resize is novel approach to this. Good idea!
Byron Whitlock
@Byron Whitlock: Resizing is the standard solution to this. StackOverflow forcibly resizes avatar icons and then translates to PNG to scrub this type of exploit.
Ben S
Resize won't work against GIFAR: http://securityandthe.net/2008/08/04/even-more-gifar-details/
oggy
maybe I don't understand this attack vector, but if the image can compromise a browser, why wouldn't it compromise the image resizing program? I would think that if it's an image, you display it, and if it's something else, it will be executed. If that's not how it works, it sounds like a browser security issue, not something to be solved server side. Please enlighten me.
rmeador
+1  A: 

Related: ensuring uploaded files are safe

Any kind of hidden exploit like you describe should not affect the server because of the way you handle it. You're simply storing binary information, and retrieving binary information, without processing it in anyway. Browsers attempting to display exploited content might be at risk, but standard image types are fairly safe.

If you'd like to be safer, you could run an anti-virus on each uploaded file. If you're on a *nix platform, you can use the industry-standard ClamAV.

I'd be more worried of someone trying to upload a very large image file.

Ben S
i am also checking silesize. thanks for pointing that out though.
mistero
For windows users there is also ClamWin, another excellent product.
Chris Lively
A: 

You can do 2 things. Serve your images from images.domain.com. this would have to be on another physical/virtual server, or firewall'd such that no open ports on the server can be accessed from that domain.

Or you can run the image file thru a java script (not javascript) like the one here. This will tell you if there is a jar file embedded in the image.

More info on this issue here:

http://www.gnucitizen.org/blog/java-jar-attacks-and-features/

Byron Whitlock
how would i serve them through another domain if the whole purpose is to make the url tiny? i need to readfile() it...i could just disable jar execution on my server right?
mistero
+5  A: 

MIME type checks will not solve the GIFAR issue. 2009's JREs are already patched, but if you want to solve the issue you can either

  • Serve your images from a different domain
  • Run a server side code to check if an image contains a valid JAR, like mentioned here

Anything else (short of denying the file to any Java enabled browser with an old enough JRE) may fail on specific cases.

Also remember that to perform a good attack with this technique your server infrastructure would have to be somewhat open (the fact that a request comes from the same domain doesn't mean that you should give any information it asks for.)

Vinko Vrsalovic
+1 Thank you. Seems some people have never heard of this exploit
Byron Whitlock
MIME-type is reported by the clients browser -> it can be faked quite easily.
Jacco
A: 

I didn't actually even hear about this attack before your question, so first off, thanks for enlightening me! Googling around, it seems that there are basically two different attack vectors here. Both include the attacker luring "regular" users to a malicious site pointing to the masqueraded JAR file, and both have to do with the fact that the JAR will be executing in the "context" of your site (i.e. the origin will be your site).

First attack has to do with the applet being able to read user cookies, which basically means it'll be able to steal the user's login information for your domain.

The second one has to do with the fact that the applet is now allowed to open connections to other sockets within your domain, which is pretty bad if one of the users behind your server's firewall visits the malicious page (enabling the attacker to effectively bypass your firewall).

So this attack does not necessarily harm your server directly, but it does harm your users - and hopefully you care about your users. The two things you can do ensure their safety have already been mentioned in most of the other answers and are summarized on this page.

oggy