Orange County Security SIG

Notes and comments of a Special Interest Group on computer security.

November 12, 2007


More Mozilla protocol handler woes (XSS)

Two new vulnerabilities for Firefox have surfaced recently. Like the vulnerability a few months ago they involve the protocol handlers at the beginning of a URL/URI (http: or https: for a web page). But unlike the previous problems, Mozilla can't lay the blame on Microsofts shoulders and this time it is the only browser to have this problem.

Some security experts are realy getting tired of Mozilla's security issues. Not only have there been several in the last few months, but this is one that was known at Mozilla for over a year. One of the reasons for going to Mozilla/Firefox was that there were fewer security issues than IE and Mozilla responded to them quicker than Microsoft did. Both of those reasons have recently been shattered and Opera is becoming more appealing every day. The JAR: problem was pointed-out to Mozilla developers in February and they knew about the DATA: problem back in 2005.


In both cases, the victims cookies for that site can be read or stolen leaving any authentication information in them open game. Or the code could simply pretend to be the victim. These techniques can also be used to get around a firewall at the infected site.

They both can result in XSS (cross-site-scripting) attacks so lets start with some XSS basics. When you are sent from one site to another, the browser gives all the scripts on the original page the same security rights that as the page it is directed to. This is compounded in this case by the fact that you will see the original URL in your address line and don't realize what can happen at the site it is sending you to.

To illustrate what this means: when you are logged onto Google there is a cookie with all your authentication information like your password. No other site is supposed to be able to see that cookie. That cookie is supposed to be safe from any script that is not on Google's site. But if a XSS sends you to Google a script can get that cookie and pretend to be you. It can read your mail or setup Gmail to send the hacker a copy of your mail without your knowing about it. I have seen a POC that reads your contacts which is bad enough.

Not only does the Firefox browser redirect you without the your knowledge but it does it without javascript. The classical XSS (cross-site-scripting) attack needs javascript to succeed so many sites would look for javascript in a users input and either neutralize it or completely eliminated it. Now the rules have just changed. While big sites like Google and MySpace have very sophisticated filters to avoid any javascript, if Javascript isn't necessary anymore then you'll be vulnerable anyways.


  1. a ZIP-like file is uploaded onto a server
  2. a JAR: URL linked to the ZIP-like file exists
  3. some one clicks the above URL
  4. the redirect is used with a "refresh" header, not a "location" header


  1. use a proxy or an application firewall and filter any references to a jar: URL.
  2. use the NoScript extension, version and later. (options -> advanced -> JAR)
  3. update Firefox that is due out next month
  4. always logout of any important site


  1. block jar: URIs at the proxy or firewall
  2. block URLs containng references to the jar protocol by means of a reverse proxy.
  3. filter MIME types so the content actually transmitted can be more easily detected.


A JAR file is simply a compressed file to archive Java programs called "classes". A protocol handler "jar:" was defined by Sun Microsystems and allows you to pass a URL to a JAR file.

But the file uploaded doesn't have to be named a JAR file (EXAMPLE.JAR). Any compressed archive file will do, not just Java.

A compressed archive file is basically what we call a ZIP file. A JAR file is only a ZIP file for Java programs (aka classes). So files like Open Office's Open Document Format or Microsoft's Open Document can also be used. One way to do this is to name a file (EXAMPLE.ZIP) with the jar extension (EXAMPLE.JAR).

But the exploit works even if the JAR file doesn't have the JAR extension. You can create a file that will look like both an image and an archive file. If you double click on FANCYEVILIMAGE.JPG below it will distplay FANCYEVILIMAGE.JPG. But if you change the extention back to ZIP you can get EVIL.JAR's contents with WINZIP (Windows) or GUNZIP (Linux).

In Windows


In Linux


There was some speculation about whether or not other common protocols were affected or not. Dennis Henderson at GRC.COM explains it well:

"Thunderbird doesn't understand "jar:" as an application or protocol (in the sense of "mailto:" or "news:"), so it just passes the command to Windows, but Windows doesn't understand it either, so nothing happens. This is all moot in any case because the exploit, if successful, would use HTTP to access one's Gmail account. The fact that the would-be victim uses a local POP/IMAP/SMTP client is irrelevant because it isn't a POP/IMAP/SMTP attack, it's an HTTP attack."

Now some people took this to mean that if they got their Gmail with POP3 they were immune. But the fact is that their email is available on Googles HTTP web site so they are vulnerable as the rest.

data urls

The other problem is the "data" protocol handler. This is has similar results as the JAR: problem but it doesn't require anything to be uploaded.

This was supposed to be a simple way to transfer information between a user and a remote server. But unfortunately it is treated like the JAVASCRIPT: handler but it isn't checked-out like the JAVASCRIPT handler. So basically it can run javascript without Mozilla knowing or caring about it.

The main researcher () points out that firefox, unlike Opera or Safari, "treats data URLs like JavaScript URLs". He also said that "data URLs are taken lightly mainly because, in the past, they were not given the same privileges as JavaScript URLs".

A simple Proof Of Concept is that the following DATA: line will execute as if it was a JAVASCRIPT: line. Unfortunately, the browser doesn't stop it and most Javascript filters ignore it.

Instead of simply opening an alert window, the code could redirect you to a malware site or act like any other Cross-Site-Scripting techniques and run inside another site with your security settings.

The main researcher to the jar: and data: problems is Petko D. Petkov (aka PDP), the founder of the security think-tank "GNUCITIZEN.COM".

The fact that Google was especially vulnerable was discovered by Michal Zalewski, a white hat hacker from Poland. His site is In 2005 he wrote the book "silence on the wire" by NoStarch publishing.


some other interesting sites

Comments: Post a Comment

Links to this post:

Create a Link

<< Home

Experience the computer club and all it's SIG group that meet at Chapman university, California on the 1st Sunday of every month.

SECSIG meets in the Science building 203 at 11:15 am.

By attending the SECSIG you can ask questions and open discussions about troubling situations you are having now.

The RSS feed address is

Dave Keays, SIG leader

This page is powered by Blogger. Isn't yours?