[pdp] provides some perspective on the news regarding the GIFAR attack developed by researchers at NGS Software. As he explains, the idea behind the attack, which basically relies on combining a JAR with other files is not new. Combining JAR/ZIP files with GIF/JPG files will create hybrid files with headers at both the top and bottom of the file and allow them to bypass any image manipulation library as valid files. While tightened security and more stringent file validation practices are advisable, the problem is larger than just a vulnerability in browser security. ZIP is an incredibly generic packing technology used everywhere, from Microsoft files to Open Office documents, and of course, in JAR files. He closes with, “any file format that is based on ZIP, you allow your users to upload on your server, can be used in an attack”
[photo: Jon Jacobsen]
I’d bet people are racing to use this to do root kit droppers already for bot nets. If someone used this with a modified Rustock.C, most windows users would never know.
No. Not really. This really just breaks the trust models of the browser. It allows you to impersonate user X of Y website if you have upload said GIFAR to Y website and have user X visit a site you own during the time he is logged in.
Head over to my other posts under the other GIFAR Hackaday post for more information or look them up online.
This doesn’t lend itself to rootkits any more than just an java applet.
Could the vulnerability be eliminated if the image-hosting service converted the image (e.g. with ImageMagick) before making it available? I mean, if you send a “gifar” (or a JPEG with a zip tacked on the end, or whatever), then it gets converted to a JPEG with the same dimensions, color depth, etc., would the converter ditch the non-image-related information at the end automatically?
That’s one of the suggested “patches” for removing the java applet portion from your website. re-saving it in this way or in another format altogether should render the Java classes pointless. Yes, definitely.
Keep in mind that any compressed image format (unless it is lossless) will lose quality each time your open and save it – no matter what the software. JPEGs are notorious for that. It’s because each time you open the image you get a near duplicate of the last image – so good our eyes can’t tell the difference. There are small differences in many of the pixels. Resaving the jpeg does calculations based on the “false but close” pixel data. Next time you open it the data is degraded just a little bit more.
Make sure your site doesn’t promise a lossless transfer. I wouldn’t do this on a photo website (like flickr) for example.
@Snider: I forgot about the signed applet feature Java uses for I/O; is that what you’re talking about? I think HTTP calls can be done without the warning even in the latest VM, so yeah session hijacking would probably work depending on how the CGI for said site handled sessions(cookie, IP, etc..)
For the typical user though, you can usually get them to fall for it, and do the human intervention part for the applet warning. After that you can do file and registry stuff, but no hooking etc..
Oh, no – this isn’t a signed applet. That’s where this breaks the browser security model. I’ll try to make this really clear.
Let’s say there is site X which allows an image upload. It checks to see that uploads are valid images by following image format specifications. Attacker Mike combines a GIF/JPG with a JAR file such that the file is both a valid image file and a valid JAR file. The JAR file contains an applet. He uploads this hybrid file to site X.
Later, on Mike’s own site he adds an applet tag to a page. He points codebase at the image file he uploaded to site X. The file he uploaded _is a valid image_, so it got through the site’s filters. But the file also _is a valid JAR file_.
Victim Y stumbles (or is social engineered) onto Mike’s site. Victim Y is logged into site X. His browser downloads the file that was uploaded to site X and says “yep, this is a valid jar file”. It starts the applet. It also says, “because this applet was downloaded from site X, site X must be hosting it on purpose. That means, I, the Java VM, will allow the applet to connect to site X. In addition I’ll give the applet access to all of victim Y’s cookies”.
Cookies are often used to store session information as a way to validate logged in users. Anyone with a copy of a cookie (until it expires) is usually able to act as if they had logged in to get that cookie.
Using LiveConnect (a way to get javascript and java applets to talk) Mike can give himself the cookies (and therefore access to victim Y’s account). Alternatively, Mike can just program the applet to do things for him – like delete an account or replace the user picture with goatse. Let’s pretent site X is a banking site. The applet could be programmed to transfer money.
The GIFAR or hybrid file is easy to make. Any valid library that follows JAR (really ZIP) file specifications waits until it sees a ZIP header before it reads data. You can just concatenate two files. It isn’t just ZIPs and some image formats that are really relaxed with their specifications. As PDP pointed out on his site (gnucitizen.org) many Microsoft Word formats are just .zip files you could add extra files inside.
@snider: I get it now. I’m surprised it isn’t already in the wild.
Hi Ross Snider,
We r implementing this attack only for educational project purpose. We have doubt regarding using giffar attack to access files in linux os. please help us on this. We doubt whether jvm can allow java applet to access or modify the files in linux os.
If possible please give us some ideas regarding type of other attacks using gifar attack.. thanks a lot.
Please note: we r using only for academic purpose in closed environment.
Rock Star –
Please reread the comments above your own. As for your concerns: GIFAR does nothing to allow access to local files. The only way the JVM is given access to the underlying operating system is through signed applets (or a vulnerability in the JVM itself) – and if you have signed applets or a JVM exploit you don’t need GIFARs to attack in the first place.
So you might understand GIFAR attack perfectly (although your phrasing suggests otherwise) – the GIFAR attack just breaks the same origin policies on websites, it won’t allow you to modify files on Linux or any other OS.
If you need more reading, there is plenty to be read on Google.
What University/Company are you doing research for? Right now you are giving me every indication that you do NOT want to implement the attack for educational purposes.
If you have any more questions or would like to answer mine, please email me in private. My email address is normlegaia [AT] gmail {dot} com.