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.
- a ZIP-like file is uploaded onto a server
- a JAR: URL linked to the ZIP-like file exists
- some one clicks the above URL
- the redirect is used with a "refresh" header, not a "location" header
HOW TO PROTECT YOURSELF
- use a proxy or an application firewall and filter any references to a jar: URL.
- use the NoScript extension, version 126.96.36.199 and later. (options -> advanced -> JAR)
- update Firefox 188.8.131.52 that is due out next month
- always logout of any important site
HOW ENTERPRISE NETWORKS AND WEB SERVERS CAN PROTECT THEMSELVES:
- block jar: URIs at the proxy or firewall
- block URLs containng references to the jar protocol by means of a reverse proxy.
- 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).
COPY FANCYIMAGE.JPG+EVIL.JAR FANCYEVILIMAGE.JPG
CP FANCYIMAGE.JPG FANCYEVILIMAGE.JPG CAT EVIL.JAR >> FANCYEVILIMAGE.JPG
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.
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.
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 http://lcamtuf.coredump.cx. In 2005 he wrote the book "silence on the wire" by NoStarch publishing.
some other interesting sites
- An explanation about how to steal cookies using a DATA: URL
- Mozilla developers discussing the DATA: problems late last year
- a description of the DATA: URL from over a year ago
- howtos about some of the techniques used in this exploit
- The author of NoScript (Giorgio Maone) blog
- how web developers can avoid XSS attacks
- a list of XSS techniques
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 http://ocsecsig.blogspot.com/atom.xml
Dave Keays, SIG leader