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:jar:http://someserver.com/some/path/somearchive.jar!/some/internal/path/resource.jpg
As you can see, after the jar: scheme we’ve got a regular http: URL (http://someserver.com/some/path/somearchive.jar), 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 http://someserver.com/some/path/somearchive.jar, in our example), then extracts the required resource (resource.jpg, 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 likejar:http://someforum.com/images/avatars/ma1.jpg!my_evil_page.html
Worse, my page’s JavaScript code will run in the same domain as the hosting site, i.e. someforum.com, 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 “jar: 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 http://someforum.com/images/avatars/ma1.jpg? 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 ;)
Update:
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 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 and Ryan Naraine ackneledged it by wroting a follow-up honestly reporting it.
No comments:
Post a Comment