Firefox feature introduces danger

Firefox feature introduces danger

Summary: Software engineers at Mozilla are working on a fix for another protocol handing issue affecting the company's flagship Firefox browser. Code execution attacks are possible under certain conditions.

TOPICS: Browser

Firefox feature introduces dangerSoftware engineers at Mozilla are working on a fix for another protocol handing issue affecting the company's flagship Firefox browser.

The flaw, originally reported in February 2007 and independently discovered by Petko D. Petkov, turns a little-used Firefox feature into a security risk that could lead to cross-site scripting attacks.

Secunia explains:

The problem is that the "jar:" protocol handler does not validate the MIME type of the contents of an archive, which are then executed in the context of the site hosting the archive. This can be exploited to conduct cross-site scripting attacks on sites that allow a user to upload certain files (e.g. .zip, .png, .doc, .odt, .txt).

The "jar:" protocol is designed to extract content from compressed files.

A vulnerability note from US-CERT suggests there may code execution attack scenario:

This vulnerability may allow an attacker to execute cross-site scripting attacks on sites that allow users to upload pictures, archives or other files. If the user opens the malicious URI with a Firefox Addon, an attacker might be able to execute arbitrary code.

The bug has been confirmed in fully patched versions of the open-source browser. In the absense of a patch, Firefox users should avoid follow untrusted "jar:" links on suspicious Web sites.


Protocol abuse adds to Firefox, Windows security woes

More Firefox URI handling security hiccups

Command injection flaw found in IE: Or is it Firefox?

Microsoft should block that IE-to-Firefox attack vector

Mozilla caught napping on URL protocol handling flaw

Topic: Browser

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Oh Oh, I know the answer to this one...

    Install the [url=]NoScript plug-in[/url] and put a 'check mark' on 'Forbid Java' in 'Options'.

    How many public sites uses Java nowadays?

    That [i]should take care of it![/i]

    D T Schmitz
    • Don't install Java.

      Just another attack vector and kills performance. Besides if you kill all scripting on a browser, it is very secure including IE. However function goes into the crapper.

      Oh, not all scripting is dangerous so I use the user.js file to fine tune it instead of overkill No Script.
      • It's not Java

        If you carefully read [u=]the US Cert advisory[/url], you'd know Java has nothing to do with this vulnerability.
        It can be exploited using just JavaScript from a document placed inside a JAR file disguised as an image, an html page or anything else.
        This will work no matter if you've got Java or not, try this [url=jar:!/test.html]POC[/url] from the [url=]Mozilla bug report[/url].
        At current date, only [url=]NoScript effectively blocks this attack[/url], [b]even on sites where you've got JavaScript and Java enabled[/b], by preventing JAR resources from being loaded [i]as documents[/i].
        Giorgio Maone
        • Not taking any chances with that swiss cheese code.

          If you disable javascript, you will get the same thing as No Script. I believe No Script is overkill and not all scripting is dangerous. It is either on or off for a website and cannot fine tune for different scripting options. The user.js file or about:config can fine tune so you don't destroy functionality. Also your link stated as one solution to use Greasemonkey as a work around when No Script breaks function. No way buddy. Greasemonkey has its own issues and security holes in its history. I have very good luck doing it this way plus you learn the different functions.

          I also don't trust zip files from unknown sources. Not a problem.
          • You're a bit confused

            you wrote:
            >If you disable javascript, you will get the same thing as No Script

            You're wrong: NoScript lets you keep JavaScript enabled on sites where you need it, and blocks exploitation of this vulnerability even if you've got JavaScript enabled, by preventing JAR resources from being loaded as documents.

            >Also your link stated as one solution to use Greasemonkey

            Uh? what link? I did not mention Greasemonkey anywhere...

            >I also don't trust zip files from unknown sources. Not a problem.

            You still don't understand how this vulnerability works. You don't need to open any zip or jar file, just stumble upon on a malicious web page: read carefully [url=]this beford's post[/url], including a Google exploitation proof of concept.
            Giorgio Maone
          • I am afraid you are confused.

            It is when it is set to no script on that site. But when set to enable on that site, it lets everything script.

            Just turn off javascript and it does the same thing. I do not know which website that takes advantage of this exploit. I turn it off until the patch comes out. I take no chances. I have been doing this for years on Mozilla and never got hosed.

            You don't read any of your links? That figures.

            Not according to the link you provided. It is a jar function that is specific to opening a zip file that doesn't mime properly. You might want to read the links you provided. I don't open untrusted zip files so this is no problem.

            Go to the last comment.

            Go to comment #2.

            I will not use No Script for I don't like it and it offers not much. Plus I have to trust you guys not to have bugs either. I would rather turn off the dangerous javascript functions with the user.js file instead of breaking all functionality on all websites.
          • OK, I'll expain this slowly, read my lips...

            Please read [u=]this article[/u] [i]carefully[/i], following all the links.
            Then you may finally realize that:
            1) This vulnerability doesn't need Java to be exploited.
            3) This vulnerability [i]may[/i] need JavaScript to be exploited, but depending on the attacked site there's likely some bad stuff you can do with it even if JavaScript is disabled (e.g. bypassing same-site referer checks)
            3) You don't need to open any "zip file" directly to be attacked, you just need to open a page containing an invisible iframe (i.e. you can't tell where you're going to be attacked). Furthermore, the "zip file" doesn't need to be named ".zip" nor ".jar", nor to be hosted on the same site the attack comes from, see [u=]comment #50 on the Mozilla bug[/u] by Michal Zalewski.
            4) NoScript protects you from this kind of attack wherever it comes from, i.e. [b]no matter if JavaScript is enabled or not for that site[/b], because it prevents the jar: protocol from loading documents, which is the root of this evil. That's what says (this link I did not just read, I entirely wrote its content too...)

            This means that completely turning off JavaScript is overkill and may not protect you entirely, while the only way to protect Firefox until the bug is patched is using [u=]NoScript[/url]. Period.
            Giorgio Maone
          • And read my lips.

            I don't install Java because it is full of security holes in its own right. Sun has a new version each month and flash is replacing it anyway.

            Without javascript enabled, your browser is pretty much bulletproof. No Script cannot shut it down any further.

            I have iFrames shut off also in the CSS file. According to the link at Mozilla, this vuln. had to do with application/zip with how a jar file handled it. I will believe the Mozilla folks before some guy hawking No Script.

            No Script is overkill also, more overhead and I also want some benign javascript functions on dangerous websites. Remember the word benign so my browser isn't crippled. There are better ways of protecting yourself. The only way to get hosed is to open the malformed file to begin with, which is something I don't do. By the way, Mikey was being cute by crashing the browser, but if you turn off javascript, it didn't crash.

            No Script Sucks! It turns off all javascript function intead of just the dangerous ones making the browser crippled. So why not turn off javascript. This is why I will not use it because there are no fine tuning features in No script. Fine tuning means not only the ability to turn of the scripting per website, but to turn off the javascript line by line per website for total control. The other features can be disabled using other methods if you are stupid enough to open malformed files. Actually you don't have to do anything if you don't open unknown files from unknown sources.


            "Jesse Ruderman

            Any site that allows image uploads (e.g. avatar images) without binary content
            sniffing is likely to be vulnerable to XSS (in Gecko browsers only) as a
            result. An attacker would only have to upload a malicious zip file to the site
            and get users to follow a jar: link.

            Possible fixes:

            * Refuse to open zip file contents with jar: unless the file has a mime type
            appropriate for zips, such as application/zip.

            * Make jar: not be considered same-origin with the rest of the hosting domain,
            but only with other contents of the jar.

            * Both of the above."

            I will believe Jesse over you because someday you will have to turn off No Script to see that webpage correctly and use common sense and not open the zipfile. Sooner or later people have to wise up to the fact not to open up everything. Security is between the chair and the keyboard.

            Like I said, No Script sucks! Not everyone is going to like what you write and you think it is the next thing to sliced bread. Get over it.
        • JAR is basically ZIP

          To provide a bit more context...

          A JAR file is basically a ZIP file containing a certain file structure.

          A JAR file should really be treated as part of the directory tree of the site it's sourced from, as far as security is concerned.
      • NoScript has its uses.

        The reason NoScript is so useful is that it allows you to restrict what scripts can run. Only doing so for known trusted sites (Google, for example) is wise.

        As for the jar: protocol, I too have never seen this. OTOH, how many have seen irc:// links? And yet, I use those all the time. The key is, it isn't a browser-based protocol, but one supported by mIRC and other IRC clients while they are running. Pretty useful, as it makes for very quick entry to specific chat rooms on IRC. (and no, IRC is not ate-up with peer-to-peer via DCC; that impression is quite false. I know that the server I have been a staffer on since 2001 has a very strict policy that even precludes use of file-share bots for staff use.) This is not to say that the jar:// protocol handling isn't hosed; demonstrably it is, and is under repair.

        My question, in fact, is "Is there a real need for the jar:// protocol at all?" If there isn't, then it needs to be turned off by default, and only enabled if the user needs it for whatever reason.
        Raymond Danner
        • For you maybe.

          But I can live without it. All it does is either turn on/off all scripting for a website. I need it to turn on/off only certain types of scripting for a website. You can only do this with user.js file to fine tune it. I do want some scripting for bad websites but only the benign type. You also can stop scripting with AdBlock Plus for certain websites. For example *.swf *doubleclick* blocks and*.swf will override.

          As for .jar files, they are nothing but renamed .zip files for any file extractor will extract them if you rename them from .jar to .zip. If you look in your chrome directory there are more uses for them than a chat program. Like I told the other guy, if you use zip files from trusted sources, this isn't a problem. You could save a questionable .zip file to disk and use your favorite extractor to expand it and check it out. Set all downloads to save to disk.

    • nuh uh

      didn't you get the memo? No more playing by different rules. <br> <br>
      It's either secure by Default, or it's not secure. <br>
      Also, to clear up one statement in the blog:<br>
      <i>Software engineers at Mozilla </i><br><br>
      That is to say, Google engineers. ;)
  • Non issue

    I myself have yet to see a jar: link, sure doesn't seem like much of a threat IMO...

    - John Musbach
    John Musbach
  • RE: Firefox feature introduces danger

    Now let me see. I can take a slight risk with Firefox, or I can take a much, much, much greater risk with Microsoft Internat Explorer. Gee, now that is a tough one.
  • this flaw has been discovered in February, but it remains unpatched!

    this flaw has been discovered in February, but it remains unpatched!
    • Why not, it's low impact ?

      Lots of "if" and "maybe's" in the article.

      It's a sign of how robust the code has become that they are now addressing these minor issues. They've got the big problems done, now they're starting work on these smaller ones.

      Good news all round, I'd say !
      • Are you being sarcastic, or just drunk on the FF koolaid?

  • Firefox s.u.c.k.s.

    Since I installed that update the CPU usage of Firefox has increased a lot and it is causing me problems. They did a very bad job with that update

    And no, I don't have Java enabled but I installed Flashblock (it is the only extension I installed) so I am sure flash is not causing the problem. Finally I tried disabling Flashblock to see if that was the problem, but it was not. All this started with that update.

    Mozilla: fix this problem!
    • Works fine here

      Firefox works fine and dandy here. No problems. You must have an issue with your particular install. Try reinstalling and see if you still have issues.
      • Re: Works fine here

        I use it with OS X Tiger and with Windows XP Pro SP2 and the problem is the same in both. The configuration for both browsers is the same as I described in my original post. Given this, I do not think it's coincidence or an isolated case.

        By the way, both systems are laptops, which tend to be more sensitive to CPU usage than desktops. If you are using a desktop you may never probably notice this CPU usage. For example, Flash generates a lot of CPU usage but it does not interrupt me too much when I use my desktop computer, except if I have too many programs loaded. I guess *your* configuration is the one that is not allowing you to see the problem.