On GIFARs

Ever since Rob McMillan of IDG published a story giving a preview of our coming Black Hat talk, specifically a preview of the portion of our talk related to GIFARs, media coverage of the research has swirled a bit out of control and there's been some misconceptions.  My co-presenter John Heasman has a write-up on GIFARs that explains this all just a bit more.

We of course want to avoid giving all of the details until Black Hat, where it will be much easier to demonstrate with an example, but this should clear up some of the misconceptions.  If you happened to see PDP of Gnucitizen give his talk at Black Hat Amsterdam last year, this combination of images with applets stuff might not be brand new to you.  We were unaware of PDP's research at the time of our discovery, but that was fortunate, for it allowed us to take a different path, using HTTP requests to piggy-back the browser's cookies.  To clarify, PDP's research and ours is similar only in the fact that we both use applets within images to accomplish our goal of attack.  Heasman explains the usefulness of this on his blog, so I won't rehash it here.

We're excited to present on this topic, but we are even more excited for what we hope to present at Black Hat Japan, which extends this attack even further, making it more dangerous.

Keep in mind that we consider this an application level issue, as in, the web applications are those most at fault for this issue; however, it is a blended threat issue, since it uses a few weaknesses in the JVM as its exploit vector.  If you have read any article that makes it sound like Facebook is vulnerable to this, or eBay, or Google, or any other site out there, please keep in mind that most of the applications out there that accept user uploaded content are vulnerable to this.  This is not a flaw that only affects a few sites.

A couple more clarifying points:

• We load the applet, which is also an image from an <applet> tag, we will discuss how during the talk.
• The image itself is not causing execution, so theories on how it loads through the <img> tag are not warranted.  If we load it through the <img> tag, it will most likely display as an image, or not display at all.
• This is NOT a browser or OS level issue.  This attack will work on all operating systems and browsers that support JVM for any application that will accept our content in a way that leaves the applet intact.
• Shrinking, converting, resizing, etc. will NOT necessarily fix this issue as is being suggested on Slashdot.  We have been able to attack sites that do resizing, shrinking, or converting as well.
• The way to fix this is to either:
  • Sanitize the incoming content to make sure it is not a combined file (this is extremely hard to do properly).
  • Host the images on a different domain (and I do not mean a different sub-domain).  For example, if the image is hosted from images.mysite.com, we can still attack www.mysite.com; however, if the image is hosted from images4mysite.com, we cannot attack www.mysite.com unless we find a different upload vector that places us on the mysite.com domain.

• Even after Sun puts out a patch, it will be a temporary fix, as many sites will still accept user uploaded content and host it from their same domain.  New vectors of exploitation will arise, as they already have in the past (see crossdomain.xml policy file uploading from Rios and my talk at DEFCON last year).
• This is not brand new, the idea of combining files together is super old, used and discussed way back in  many forensics books.  What is new is how we are using this attack vector.

-Nate