The recent disclosure by pdp of the jar: protocol bug originally discovered and responsibly reported by Jesse Ruderman in February, and its redirect variant discovered and popularized by Beford with a nice Google-targeted proof of concept, spawned some interesting 3rd party coverage.
Interesting, because very few 3rd party reporters and commenters seem to truly understand how this vulnerability works, and — worse — because of the quite nonsensical advices given to protect users.
How the Vulnerability Works
The jar: protocol is used internally by Mozilla browsers to resolve and address resources stuffed inside optionally compressed archives in Zip format called JARs (Java ARchives).
A JAR URL looks like this:
As you can see, after the
scheme we’ve got a regular http: URL (
), followed by an exclamation mark separator and the internal path to find the actual resource inside the archive.
When a Mozilla browser is asked to open a jar: URL, it first downloads the whole JAR file from the server using a regular HTTP GET request (for
, in our example), then extracts the required resource (
, in our example) from the archive on the client side.
All good and handy, but here’s the problem: the jar: protocol currently assumes any nested URL following the jar: scheme actually points to a JAR, no matter what the actual content-type header or any other file type hint (e.g. the file extension) suggests.
This means that I can stuff a malicious HTML page of mine inside a Zip file, rename it as “ma1.jpg” and upload it as my avatar on a message board.
Then trick some user to open my malicious page directly through a jar: URL like
, hence I’m cross-site scripting the message board.
To make it even more nightmarish, I don’t actually need the target website to be a message board allowing file uploads: I just need an open redirect, which can be found on Google and many other “safe” places, because my disguised JAR file will inherit the security context of my victim’s redirector even if it’s hosted on a website of mine. That’s how Beford’s proof of concept works.
Did you say “Universal XSS”?
What Firefox Users Can Do
At least until a Firefox patch is released, Firefox users should install latest NoScript stable release, or even better help us testing latest development version.
NoScript will prevent remote JAR resources from being loaded as documents, neutralizing the XSS dangers of the jar: protocol while keeping its functionality. See this FAQ for more details.
Strangely enough, even if this is the only advice which works (other than switching to a different browser), it has been give only by the US Cert advisory (together with another less effective one, see below).
Firefox users should avoid follow untrusted “jar:” links on suspicious Web sites.
(Ryan Naraine’s Zero Day)
If this vulnerability is exploited in the wild, you won’t see any “
Poor Ryan has probably been misled by reading the following:
Do not follow untrusted “jar:” links or browse untrusted websites.
Admittedly, the “don’t browse untrusted websites” clause adds some correctness to this advice, but also makes it practically useless.
Furthermore, Ryan quotes the US Cert advisory as well, hence he’s got no excuses for omitting the NoScript work-around.
As we said, US Cert correctly referenced NoScript’s JAR protection, but also gave a bogus advice of its own:
Using proxy servers or application firewalls to block URIs that contain jar: may mitigate this vulnerability.
If you read how this issue works carefully, you should have noticed that all the jar: protocol resolution happens inside the browser: the only request which is sent, possibly hitting proxy servers or application firewalls, is the regular nested HTTP request. Are you going to block every image together with my innocent looking
? At any rate, your network devices are very unlikely to ever see mythological beasts like “URIs that contain jar:”…
No matter how nonsensical the advices above are, someone decided to endorse them all:
No patch is available through there are a number of workarounds (such as blocking URIs that contain “jar:” using a reverse proxy or application firewall). For home users, Secunia advises users to avoid following untrusted “jar:” links or visiting untrusted websites.
What a pity they left out the only one which does work ;)
application firewalls and proxy servers can be used to block Windows Universal Resource Identifiers (URIs) that contain the JAR protocol
They actually reference NoScript, but in a quite misleading way:
IBRS security consultant James Turner, who has used the NoScript add-on, said protection against these vulnerabilities can be a trade-off between security and a rich online experience.
In the meanwhile, Ryan Naraine wrote a follow-up honestly reporting my criticism (notice that I had privately emailed both him and The Register’s John Layden with no answer, before deciding to write this post of mine).