Web Mayhem Firefox's JAR Protocol issues

One of the things that we enjoy the most, here at GNUCITIZEN, is finding issues in features. Unlike bugs, insecure features tend to be more severe and usually last longer due to uneasy and rather long decision making process on whether the feature should be continued or discontinued once and for all. In my previous post I outlined some of my concerns about the data: protocol. Today, I would like to draw your attention on the insecurities that come with my personal favorite: jar:.

For those of you who have never heard of jar:, the protocol is nothing more but a mechanism for pulling content from compressed files. In its most basic usage form, the jar: protocol looks like this:

jar:**[url to archive]**!**[path to file]**

Notice that the protocol embeds another URL in its body. This URL points to the location of the JAR(ZIP) archive from where the **[path to file]** will be read. The secondary URL can be of any kind, including but not only: chrome, file, ftp, https and even data (we will come back to this one latter). The **[path to file]** parameter usually starts with slash (/). This part of the URL specifies the relative path from the JAR root. In case we have a single file called `a.jpg` within the folder `Pictures`, the path will look like this: `/Pictures/a.jpg`. The full URL path may look like the following:

jar:**https://domain.com/path/to/jar.jar**!**/Pictures/a.jpg**

If you want to learn more about the jar: protocol just look it up on the web. One thing that is very important to stress, and which we are going to use as a basis for the rest of this post, is that jar: content run within the scope/origin of the secondary URL. Therefore, a URL like this: jar:https://example.com/test.jar!/t.htm, will render a page which executes within the origin of https://example.com. It is very important to remember that.

"What does this all mean?" In simple terms, it means that any application which allows upload of JAR/ZIP files is potentially vulnerable to a persistent Cross-site Scripting. Potential targets for this attack include applications such as web mail clients, collaboration systems, document sharing systems, almost everything that smells like Web2.0, etc, etc, etc. Document formats are in particular very vulnerable. The OpenOffice file format (odt) and the less known Microsoft Office 2007 Open Document Format are both based on ZIP. If you create a simple document via either of these products and then you change the extension to .zip, you will be able to read all the files the document is made of. An attacker can simply add a malicious page, with a nasty client-side exploits, inside the archive and change back the extension to .odt or .doc. Who would have though that?

Once the malicious Zip/Doc/Odt/Etc/Etc/Etc file is uploaded/shared the attacker will be able to cross-script the origins in whatever way he likes. My research led to the discovery of many applications that are affected by this issue including some coming from top software vendors such as Google and Microsoft. Their number is so big that it makes almost no sense to try to list them all here or even be bothered to individually investigate all of the related issues in detail. The root cause is only one: the jar: URL protocol handler.

But this is not all! Jar URLs can be used to obfuscate malicious payloads to an extend which no Anti-virus software can recognize. The protocol handler can be nested (jars within jars within jars) and can encapsulate the data: protocol as well. Attackers can easily write a self extracting payload which is hidden behind multiple permutations of the both jar: and data: protocols and as such evade intrusion detection and prevention mechanisms that might be on place to guard the perimeter.

What shall we do to protect ourselves?

I haven't thought well on this yet but the best way is to very carefully sanitize the types of files you allow your users to upload/share. Unfortunately, sometimes this is impossible, especially when it comes to formats such as .odt and .doc. You need to open these files and re-save them and as such to guarantee that there are no malicious leftovers. IDS, IPS and Ant-virus vendors should really start looking into how the jar: protocol works and come up with dynamic mechanism for uncompressing deeply nested URLs.

Archived Comments

kuza55

Nice find pdp! This could probably also be used to avoid protocol blacklists which blacklits data: URIs as well to avoid XSS filters, and not just IDS'.

severity

I get document.domain = null with: jar:http://example.com/1.zip!/1.html

Gustavo Bittencourt

The bug 369814 became public after your disclosure. https://bugzilla.mozilla.org/show_bug.cgi?id=369814

rado

it doesn't work on Opera

pdp

I would like to stress one more time that any file that is derivative of ZIP can be used as an attack vector. Moreover, if an archive contains dynamic content such as Flash or HTML, which are vulnerable to attacks, attackers will be able to use them for their benefit.

firefox

wonderful,i like this blog

Wisec

Nice find Pdp! Even if you discovered it independently, in Bugzilla.Mozilla.org, the developers found this issue on Fabruary 2007 (with a p0c too)! I think it's unbelievable that such high impact issues take so much time to fix!! Just a suggestion to Moz-Devs: At least as a quick and dirty fix, add in about:config a flag option which prevents remote site to use data: and jar: and chrome: and whatever. One option for each proprietary/odd uri scheme. oh, standards answers like "use noscript" will be redirected to /dev/null. Again kudos to Pdp :)

Giorgio Maone

Hi pdp, Latest NoScript development build took a quite drastic but reasonable (considering the behavior of other browsers) measure about JARs. JAR resources can still be loaded as images, applet classes and the like, but they cannot be loaded as documents. http://noscript.net/getit#devel

pdp

good news as always! :) 10x Giorgio.

G-Brain

Very, very nice. Another place to use this kind of thing would be a forum that allows attachments.

Sam St-Pettersen

Maybe a local file restriction would be sensible. From my understanding, the only (justified) legitimate use for jar: is in Firefox extensions or XULRunner applications. Allowing their use in an online context can probably be avoided without any real backlash. Of course, I might be wrong. But I've only seen jar: used legitimately for the aforementioned purposes.

Sam St-Pettersen

BTW Is that a photograph of a young(er) Brenden Eich? :)

pdp

heh, I don't know but it would be funny if it is :)

Kibitz

Regarding the nested jars within jars within jars that could contain a virus or other payload: what about A/V that scans at runtime? There are still lots of other considerations to be made, but this may be one small consolation to the huge list of issues that this discovery makes.

.mario

Reading the mozilla.org bug lists is like a Saturday noon shopping session ;) Anyway - as a developer you must _never_ trust user input especially when coming to uploads. 1. Check MIME Type 2. Check image size 3. Check for HTML/PHP like patterns in the images source (http://phpfi.com/274478) 4. Transform the image (other size AND other format) 5. Finally place the image in the upload folder Greetings, .mario

pdp

.mario yes, but I would like to stress one more time: any file can be used to carry the attack. Even TXT file can do the job. So for example, let's say that your application allows export of documents as TXT files. This is a potential problem.

Kishor

Nice! as always..

beford

pdp, this can also be abused if the site has an open redirect issue, I've posted a simple poc on my site. This makes the amount of 'now' vulnerable sites bigger :)

pdp

beford, I wrote a new post just for you :) very nice find!

Peter da Silva

I see a few other issues here. First, there's a problem in the basic design of the handler. Conceptually, the file is not accessed through a "jar:" protocol, the fact that the file can contain content is an attribute of the file. It's the MIME type of the file that should result in the file being treated as a JAR file: http://example.com/path/to/file.jar#/path/inside/jar/file.html... This would have avoided this problem right from the start. Second, allowing arbitrary access to the contents of untrusted archives in any context is dangerous. Apple's been burned by this, Microsoft's been burned by this. What is the benefit of this handler that makes the risk worthwhile? Third: assuming this is allowed, the file should be treated as part of the directory tree of the hosting site. If it's redirected, that's the site in the redirect, not the site in the original URL. Are there other situations in Firefox where the original URL rather than the redirected URL are used for this purpose?

opera11

It is interesting issue :) Good, that i dont use FF :)))

sanjuro

Never heard of that "jar:" protocol. I wonder if this issue has been fixed by Google, Microsoft and everyone else since this post.

corrector

"Never heard of that “jar:” protocol. I wonder if this issue has been fixed by Google, Microsoft and everyone else since this post." Hug? What is this nonsense all about? There is not/was not, "a Google, MS and every one else" bug. There is (was) an awful, ridiculous, crazy, MS-sh*tware-style exploit-invitation-by-design FF obscenity. No one needs to fix anything except Mozilla. Someone needs to be fired, and that someone is actually so many people. FF credibility is ruined *forever* (or until this team is fired for good).