One of the things that we enjoy the most, here in GNUCITIZEN, is finding issues with 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:. Before we continue I have to say that pointing design problems is a very important task. We don’t want to deal with the bad news too late, do we?

Safari till vänster, Firefox till höger

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

Enough theory for now. If you want to learn more about the jar: protocol just look it up on the net. What is more interesting, is to explore the security considerations that emerge when it comes to this protocol in particular. Unfortunately, many of us missed to point out the problems and as such almost all applications on the Web seams to be vulnerable to one degree or another, when using Firefox, as a result. 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 but real Microsoft Office 2007 Open Document Format are both based on ZIP. If you create a simple document via either of the products and then you change the extension to .zip, you will be able to modify the format in raw. The attacker will simply add a malicious page, with a nasty client-side or server-side attack 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 attackers will be able to cross-script the origins in whatever way they like. 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 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 permiations 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 to protect against the upcoming jar: protocol attacks 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.

I almost forgot to mention, but jar: URLs may also elevate the importance of DOM based Cross-site scripting attacks. Simply put, if you have you host ZIP/JAR files which contain poorly programmed dynamic content, they can be used against you. This means that pentesters now should start looking for this type of XSS vector as well. I hope that this post was educational and at the same time eye/mind-opening. Oh, source code repositories are also very vulnerable due to jar:! What a day!