Wednesday, December 17th, 2008


Last week, Sun released a patch for a vulnerability I reported to them.  The patch I’m talking about fixes the “GIFAR” issue.  I was unable to speak on the issue at Black Hat (for various reasons), but Nate McFeters did a great job of presenting the concept of GIFARs at Black Hat USA along with a simple example of how an attacker could use a GIFAR in an attack.  Now that the issue has been patched, I’d like to cover some of the things related to “GIFARs” that I thought were interesting (including a few items that were not mentioned at Black Hat).

Before we begin, I’d like to thanks Chok Poh from Sun’s Security team.  Chok was vital in fixing the GIFAR issue.  This patch required some significant thought as to how to best handle this issue.  Chok was very responsive and was smart enough to understand the impact of the unusual issue.  I’d also like to thank the Google Security team.  Google was our “guinea pig” for testing some of the pieces related to GIFARs and despite having to redesign some of their application behavior, they were gracious and very worked diligently to protect their users.  Now, on to the show!

As shown by Nate at Black Hat, creating the GIFAR is simple, we simply use the “copy” command on Windows or the “cat” command on *nix.  There are a few different places that talk about this technique (pdp has a great write up), but I first learned of the technique from in this post.  Once the GIFAR is created, we examine the file in a HEX editor.  The header of the file looks something like this:


The footer looks something like this:


We now have a file that is both a valid GIF and valid Java JAR.  We now upload our GIFAR to our victim domain (in this case Google’s Picasa Web).  Google attempts to ensure the file is a valid GIF (which it is) and takes ownership of the GIFAR on their domain.  Once Google has taken ownership of the GIFAR, I can reference the applet on my attacking page via the APPLET tag.  I think the items above were well covered at Black Hat and it is these concepts that represent the essence of a generic GIFAR attack… but Google is smart and they understood the dangers of insecure content ownership before GIFAR, so let’s looks at how we bypassed these Google specific protections.

When we first examined the GIFAR we uploaded to Picasa Web, it wasn’t actually served from the domain.  The actual domain it was served from  Below is a screenshot of the domain Google was using to serve the user supplied images.

Google Alias

After some investigation, we realized that was actually an alias for  So, we could manually change our request from to

Bingo!  Now we are on a domain!  From here, a lot of attackers begin to think “Java has raw sockets…”.  It’s one of the first avenues we approached, but we quickly discovered that raw sockets aren’t as useful as other techniques.  Instead of raw sockets, we chose to use Java’s HTTPUrlConnection object.  We chose the HTTPUrlConnection object for two very good reasons.  The first reason is HTTPUrlConnection uses the browsers cookies when making request to domains.  So, if our applet is stored on and the user is signed into Google, we get to piggy back off the victim’s cookies.  We’ll get to the second reason here in a bit.


Now, even though we are now on the domain, we still have a problem.  The Java Same Origin Policy allows the applet to connect back to the domain that served the applet (I’ve covered this behavior before in previous posts).  Considering the applet was served from, the attacker is allowed to use the applet to connect back to and only  The problem here is doesn’t store anything interesting.  This problem leads us to the second reason we chose the HTTPUrlConnection object.

Java’s HTTPUrlConnection object has a method named “setRequestProperty”.  Using setRequestProperty we can set arbitrary HTTP headers for our GET and POST requests.  We use the setRequestProperty to set the HOST header for the HTTP request, allowing us to “jump” from the domain to any other sub domain.  As a simple example, I had discovered a contact list at (Google has removed this contact list).  I set the URL object passed to the HTTPUrlConnection object to  I also set the HOST header to


When the request is made, Java checks the value of the URL object to ensure the Same Origin Policy is enforced.  Since the domain of the URL object is, everything checks out and Java lets the request through.  Once Google receives the request, it checks the HOST header to determine where the resource should be served from.  The HOST header specifies that the resource should be served from, so despite the fact that the URL points to, Google serves the contact list from  In this example, I stole a user’s contact list but it could have been any content from a number of Google sub domains.

All your contacts are belong to us

It’s easy to blame Java (Sun) for this issue.  After all, it was their JRE that had a relaxed Jar parsing criterion which allowed GIFARs to be passed as Jars.  In many respects some blame could be placed on Sun, but in my opinion (as humble as it is), this is ultimately a web application issue.  When a web application chooses to take ownership of a user controlled file and serves it from their domain, it weakens the integrity of the domain.  This isn’t the first time an image was repurposed like this, IE has had MIME sniffing issues with images, Flash had crossdomain.xml issues with images, and now we have GIFARs.  The impact of these attacks could have been minimized if web applications that took user controlled files served those files from a “throw away” domain.  As an application developer, you can prevent these types of attacks in the future by using a separate domain for user influenced files.

Posted by xssniper | Filed in Web Application Security

11 Responses to “SUN Fixes GIFARs”

  1. December 17th, 2008 at 8:01 pm

    links for 2008-12-17 (Jarrett House North) said:

    […] SUN Fixes GIFARs (Billy (BK) Rios) More documentation on how the blended GIF + JAR (GIFAR) attack worked, and some thoughts on mitigating it. In particular, I like the idea of having a separate domain to store user contributed content. (tags: security java gifar) […]

  2. December 23rd, 2008 at 12:29 am

    kapp said:

    dude awesome xplanation on GIFAR…really liked the post!!

  3. January 14th, 2009 at 7:21 pm

    rajat swarup said:

    As usual awesome stuff man! Reminds me the same situation where the mismatch between proxies and web servers to use different “Content-Length” headers when more than one content-length header was specified to perform cache poisioning attacks. Just that in this case there’s a mismatch between JVM (client side plugin) and the web app in what they consider a valid HTTP request! :-)

  4. January 24th, 2009 at 4:59 pm

    Easy Server Side Fix for the GIFAR security issue « - Inferno's Blog on Application Security said:

    […] GIFAR issue was found by security researchers Billy Rios and Nate Mcfeters. To summarize the exploit, an […]

  5. January 25th, 2009 at 9:54 pm

    Inferno said:

    Hi Billy,

    I have found another server side fix for the GIFAR issue and also referenced this article at my blog


  6. February 23rd, 2009 at 12:36 pm

    Top 10 técnicas Web Hacking del 2008 | CyberHades said:

    […] GIFAR (Billy Rios, Nathan McFeters, Rob Carter, and John […]

  7. May 25th, 2009 at 2:07 pm

    Smitha said:

    Hi Billy,

    I am student from Penn State working on a project related to some issues in Web 2.0. We were researching this issue and when we tried the patch by Sun (we installed the latest version of Java and updated our JRE) , we found that we could still run Gifars. Could you please shed some light on why this could happen.
    It would also be great if you could give us some insight into how the patch by Sun works to fix this issue


  8. October 15th, 2009 at 12:34 am

    Dave said:

    Nice to see everyone saying “NICE POST” when they really have no clue of what your talking about.

  9. November 13th, 2009 at 3:32 am

    Alain said:

    You suggest that web sites use a throw-away domain for user uploaded content.

    However, this won’t help for exactly the same reason that it didn’t help in your google example: the malicious user would just use the same conn.setRequestProperty(“Host”, “”); hack that you used in your example.

    So, rather than needing only a throw-away domain, you’d actually need a throw-away server or a least a throw-away IP. Which is lots harder to come by for small website operators.

    And it is the conn.setRequestProperty hack that make this a java bug rather than a website bug. Indeed, conceivably the same hack could be used without any cross-site-scripting vulnerability or chimera file by customers of a virtual hosting service who wish to attack other customers of the same service.

  10. April 14th, 2011 at 5:21 am

    10 tecnicas de hacking web: « Hackerpedia. said:

    […] 1. GIFAR (Billy Rios, Nathan McFeters, Rob Carter, and John Heasman) […]

  11. December 2nd, 2013 at 8:07 pm

    Security issue? - PHP Solutions - Developers Q & A said:

    […] type checks will not solve the GIFAR issue. 2009′s JREs are already patched, but if you want to solve the issue you can […]

Please leave a Comment