Evil GIFs: Partial Same Origin Bypass with Hybrid Files. First there were PNGs that had crossdomain.xml files embedded in them, now there are GIFs that contain Java applets (as JAR files). At this point I’d say don’t even bother trying to validate uploaded files, just make sure they’re served off an entirely different domain instead where XSS doesn’t matter.
Sign in with 
OpenID
Actually these GIFAR files are to be executed on server, not on client.
Is that definitely true? The announcement on the O'Reilly blog is confusing - it describes this as a cross-domain restriction workaround which would suggest the applets are served to the browser and can be used as an XSS vector, but then mentions then need for a JVM on the server so you can execute the applet.
The first made far more sense to me than the second (since when do applets get executed inside a JVM? Surely you need to edit the server's XML config file to get it to load in newly uploaded code) so I assumed that this was a mistake in the article and the exploit has nothing to do with Java on the server. I'm trying to track down a more detailed explanation of the exploit to confirm this.
I found this: http://blogs.zdnet.com/security/?p=974
It's by the same researcher, but it still doesn't seem to talk about executing Java code on the server.
Serverside Java execution makes no sense - the exploit would just allow you run your injected applet in someone else's browser. But then the applet sandbox would prevent any filesystem or network access (other than with the applet's originating server).
Doesn't seem the most dangerous of threats.
phl - 1st July 2008 11:55 - #
The article I linked to in my comment above suggests that they've found ways of breaking out of the applet sandbox - possibly using anti-DNS pinning related exploits.
Indeed, although that's via a different vector, and the two attacks appear incompatible to me. The sandbox breakout works by embedding a crafted APPLET tag pointing to an applet on a 3rd party box. This GIFAR thing relies on uploading applet Jars disguised as innocuous GIFs, so I assume they get served back inside IMG tags -- no opportunity to craft the codebase tag and break the sandbox restrictions.
If both attacks can be combined somehow, then it is potentially very nasty. But then who bothers to install the Java plugin these days?
phl - 1st July 2008 15:20 - #
Actually, it seems more likely to be a two-part attack. First upload a Jar file masquerading as a GIF (to bypass content-type restrictions, I guess), then inject an applet tag via an unsanitised text input somewhere. The applet tag would point to the GIFAR you uploaded, meaning the origin server of the applet is the same as the page. The sandbox would then let you talk back the origin server again, so I guess on a social-network site you could then steal data and pass it to another member via the site's messaging facilities.
Looks like the sandbox-breakout exploit has been fixed now.
phl - 1st July 2008 15:48 - #
I clicked the link in this post and read there:
> Once uploaded onto a web site, and assuming the _web server runs a JVM_, it allows one to run a malicious java applet on someone else's web server
I didn't listened to webinar itself, so I'm not sure.
I believe what is confusing in this text is calling jar file "applet".
(BTW, I couldn't enter xhtml here: it kept saying "Text is not allowed inside blockquote" which is kinda weird)
arty - XHTML (and HTML 4 strict) require that text inside a blockquote is contained within a paragraph element or similar. It's a dumb rule, but there you go.
wow, I need to use strict modes more often : )
The assumption this exploit would execute anything on the server is simply wrong. I guess that the person reporting this just didn't really know what he was talking about.
The attack could go like this: If the browser runs the hidden applet in the java plugin, the applet has access to certain information on the page and it can establish connections back to the orginating domain.
Let's assume, the session ID is part of the URL of the page that embeds the GIFAR. The applet can then fabricate an HTTP request back to the originating server that may post a private message containing the URL with the session ID to an account owned by the attacker. The attacker could then potentially hijack.
I need to research whether an unsigned applet can access cookies (for the originating domain). If that is the case, the applet could also send those to the account of the attacker.
Lars Oppermann - 1st August 2008 16:35 - #