Archive for November, 2007

Canopic JarThe 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


Worse, my page's JavaScript code will run in the same domain as the hosting site, i.e.

, 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.
It should be noted that this specific protection is completely independent from JavaScript blocking: this means that you're protected on every site, no matter if there you've set NoScript to allow JavaScript or not.
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).

Bogus Advices

Firefox users should avoid follow untrusted “jar:” links on suspicious Web sites.
(Ryan Naraine's Zero Day)

There are several ways for a browser to open an URL automatically without your consent: JavaScript, an IFrame, a Meta Refresh, a redirect...
If this vulnerability is exploited in the wild, you won't see any "


link" coming.

Poor Ryan has probably been misled by reading the following:

Do not follow untrusted "jar:" links or browse untrusted websites.
(Secunia Advisory)

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.
(The Register)

What a pity they left out the only one which does work ;)


PC World and ComputerWorld finally joined the fun:

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:

Users can download a NoScript add-on for Firefox to block JavaScript and executable content from untrusted Web sites, and can secure their Google accounts by remaining signed out whenever possible.
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.
"The add-on works fine but it is a trade-off between reducing your online experience by blocking JavaScript and protecting yourself against the exploit," Turner said.

As I said, NoScript's JAR protection has nothing to do with JavaScript blocking and it works no matter what the content of your whitelist is: in other words, there's no trade-off at all because you keep JavaScript enabled where you need it! Oh, "security expertize"...
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).
Thanks Ryan.

So I just come back from my honeymoon journey (Greece, Turkey and Croatia) right in time to find that Sirdarckcat and Kuza55 teamed together to throw a friendly defacement at our beloved RSnake!

The kids miserably failed, nevertheless RSnake did not like it a bit.
Their payload was playful rather than venomous in my opinion, but you can judge by yourself:

0wning RSnake For Fun and PageRank

So, you're sitting on the irc channel one day and someone is poking around with one of RSnake's tools, and finds that its not working, or at least that's what it seems like untill they realise that its not just broken, its broken in a fun XSS way :) - what do you do? Do you: a) Urge the person to report the problem to the vendor (RSnake), and get mad props for being awesome? b) Scream about how the vendor is a security "expert" and needs to "secure their shit!!!1111"? c) 0wn the vendor for Fun and PageRank Well, to me, the answer seemed fairly obvious. Since the "Evil Advertising Empire" (Google), cue ominous, had done a little dance and increased the PageRank of our blogs, we had gotten a taste of the power which we could amass, muahahaha, and we wanted more! Or at least I did..... So anyway, Hey RSnake :) Thanks for the free advertising space. Anyway, credit goes to: sirdarckcat for not only being generally awesome, but finding the actual exploit. thornmaker for (inadvertently) providing us with a method to get our payload through NoScript (Javascript variable setter's and FTW!), so umm, hey thornmaker :) Gareth Heyes for doing that awesome research on selective payloads using CSS, which where implemened in the exploit. kuza55 for not really doing anything, but being in the right place at the right time but being able to get some free Googlejuice from things anyway :p Oh, and, of course: XSS! We now return you to your regularly unscheduled posting ;) - kuza55 & sirdarckcat P.S. Thanks for directing to :) P.S.2. Sorry .mario, NoScript is the new attack playground :P, we'll be back to php-ids ASAP.

At any rate, from my NoScript standpoint, nice setter+name bypass combo -- just you send me a mail next time, thanks ;)
Latest release already defeats it, but for those who disabled automatic updates, it's time to get it...

Bad Behavior has blocked 927 access attempts in the last 7 days.