Sunday

GIFAR, JPGAR, DOCAR, what's the deal with the new client side vulnerabilities.



The news about GIFARS (a hybrid GIF + JAR file) has been making the rounds. It has appeared on Slashdot and various other sites. Basically, it could allow any website accepting picture to present you this file but it would be treated as JAR by your Java Virtual Machine. Potentially leading to code execution.
But the articles lacked some technical details and was leading to some misconceptions, even being called photo viruses. There was also some confusion regarding a similar talk of pdp's GNUCITZEN at Blackhat Amsterdam last year, so some clarification was in order. So let's start with Nathan McFeters:

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 (co-presenter) explains the usefulness of this on his blog, so I won’t rehash it here.

More clarifications:
  • We load the <applet>, which is also an image from an <applet> tag, we will discuss how during the talk.
  • The mage 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. (Source: Zero Day)
Read the entire story here. It's very similar to pdp's work but as he said on the following GNUCITIZEN post, they took a slightly different road and have some new methods, not discussed before:

So yes, the whole notion of combining JAR files with other types of files is not new. It is really old and it is just enough to google about how to hide ZIP (which is basically JAR) behind JPG images. I’ve discussed the subject on several conferences in the past and I’ve gave away some pointers why this is dangerous. Now you can read my paper which explains why this is so, but for those of you who don’t want to go through 20 pages of material here is the summary: the combination is dangerous because it breaks the browser security model in a way. Think about it as an advance form of persistent Cross-site Scripting Attack. It is not just XSS but also a Socket monster as the JVM will allow us spawn sockets too.

So maybe yes, the issue is not new but what will be presented at Black Hat, and this is why you should attend this talk, is something different. The XS-Sniper crew (if I can call them that way :)) will present a technique in which they managed to get around certain restrictions/limitations when exploiting the Google platform in particular. This puts the attack into a very different prospective and this is what I am interested to learn about. (Source: GNUCITIZEN)

But as pdp in a followup post reveals, the problem is not related only to GIF files, but various other formats including .doc (office documents).

...
ZIP, which is basically JAR, is a very generic packing technology and it has been reused everywhere. For example, it has been used as the basic format for Microsoft Windows 2007 Documents. OpenOffice documents too. What about AIR applications? There are numerous examples of ZIP reuses. This essentially means that any site which allows you to upload any format based on ZIP is vulnerable to a persistent XSS plus the socket issue I’ve briefly covered in my previous post and my initial post from a year ago. And you don’t have to use the combo trick. All the attacker needs to do is to slip a .class file into a MS Word Document file among the others MS specific files and you have a problem.

The process will go like this. BTW, this is the lamest possible way of doing all this. You can do the same with a single command:

  • Change the extension from .doc to .zip
  • Put the .class file in to the .zip file.
  • Change the extension from .zip to .doc
  • Upload it to the server which you want to attack.
So, to summarize: any file format that is based on ZIP, you allow your users to upload on your server, can be used in an attack. Any format that has its headers are at the top of the file and it ignores junk at the bottom can be used in an attack. No matter which way you look at it, SUN has to do something about the issue. (Source: GNUCITIZEN)
For the full details on the new attack vectors, we will have to wait until Blackhat. Let's hope that Java will release a patch. But as Nathan said, that won't be enough. I'll start reading pdp's paper and I hope that a video from Blackhat will be released later on. To be continued.

(kudos goes to Billy Rios for having discovered this)

(Photo under Creative Commons from Today is a good day's Photostream)

No comments: