Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Mozilla The Internet Bug Security

Mozilla/Firefox Bug Allows Arbitrary Program Execution 940

Posted by CowboyNeal
from the no-one's-perfect dept.
treefort writes "An article at eWeek has the lowdown. The article also has a link to the bug report which addressed this issue some time ago. Still, I feel safer using Firefox since malicious persons are much more unlikely to target any vulnerabilites. Note that this only affects users of Mozilla and Firefox on Windows XP or Windows 2000." New releases are already available on mozilla.org that fix this. Update: 07/09 00:41 GMT by CN : I removed the bum link to Bugzilla, since I guess they don't like us. Also I discovered that OSDN's own NewsForge has more on the situation.
This discussion has been archived. No new comments can be posted.

Mozilla/Firefox Bug Allows Arbitrary Program Execution

Comments Filter:
  • A clear advantage (Score:5, Informative)

    by SIGALRM (784769) * on Thursday July 08, 2004 @05:21PM (#9647623) Journal
    The Mozilla Foundation has confirmed the problem and issued a fix
    This incident underscores why many use or have switched to Firefox: vulnerabilities discovered and promptly fixed. Not weeks and months from their publication--and not by another vendor--this exploit was addressed by those who have made available Mozilla's code for public scrutiny.

    FYI, in case you didn't read the article, you can download the fix here [mozilla.org].
    • Re:A clear advantage (Score:5, Interesting)

      by hackstraw (262471) * on Thursday July 08, 2004 @05:29PM (#9647697)
      Yeah, they "fixed" it timely. But WHY THE HELL IS THERE A shell: SCHEME IN THE BROWSER IN THE FIRST PLACE? I've never heard of it, never needed it, and obviously there are issues with it.

      Come on we blast M$ for putting vbscripting and whatnot in IE, but this is just as dumb.
      • by Anonymous Coward on Thursday July 08, 2004 @05:34PM (#9647755)
        Mozilla hands off schemes it doesn't know to the operating system (Windows), and WINDOWS executes the shell scheme. It was obviously a security flaw in their eyes, too, as they fixed it in XP SP2. If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.
        • Bad way (Score:5, Interesting)

          by phorm (591458) on Thursday July 08, 2004 @06:08PM (#9648059) Journal
          Which is basically to say:

          IE bad because it is integrated into the OS
          Moz bad because it calls the OS because it's not integrated

          Both are bad. In fact, this is quite bad for Moz, as one of the touted improvements is that not being OS-integrated avoids such issues.

          Basically, you're passing on data from the windows URI handler... so it's almost like importing a windows IE/Web insecurity into Moz. Perhaps if Moz just imported the windows URI handlers as a datafile, and stripped out known baddies?
          • Re:Bad way (Score:5, Interesting)

            by KevinKnSC (744603) * on Thursday July 08, 2004 @06:20PM (#9648144)
            Basically, you're passing on data from the windows URI handler... so it's almost like importing a windows IE/Web insecurity into Moz. Perhaps if Moz just imported the windows URI handlers as a datafile, and stripped out known baddies?

            Relying on stripping out "known baddies" means that what you're really relying on is your list of known baddies. Any new baddie is, by definition, not on that list. Stripping them out is a start (web pages don't need access to shell://), but it's not a complete solution.

            • Re:Bad way (Score:5, Interesting)

              by phorm (591458) on Thursday July 08, 2004 @06:45PM (#9648311) Journal
              Well, the alternative to that would probably be to either not allow any that aren't known good (hey, how come this dumb browser won't open file X!), or allow all or all that aren't known bad but with a warning beforehand. Unfortunately, hoards of spyware/virus infested machines show up how well users pay attention to warnings/disclaimers/etc
            • Re:Bad way (Score:5, Informative)

              by dolphinling (720774) on Friday July 09, 2004 @12:09AM (#9649849) Homepage Journal

              From the article:

              The developers considered changing from scheme blacklisting to whitelisting, in which case all schemes and protocols would be disallowed unless explicitly allowed.
              Mozilla Foundation spokesmen said a future version of the browsers will change to whitelisting, but the interim fix just disables the shell protocol. Several other schemes, such as vbscript, are already disabled by default.

              So in other words, this fix only changes a pref which is easy to do without a huge download, etc. and is easy for the clueless, since it requires one click. Future versions will have a fix for the problem in general, rather than just this specific case.

            • Re:Bad way (Score:4, Interesting)

              by ttldkns (737309) on Friday July 09, 2004 @03:52AM (#9650407) Homepage
              so it's almost like importing a windows IE/Web insecurity into Moz.

              It is in fact an IE insecurity too as i just tested it with internet explorer and windows 2000 at this link: http://www.mccanless.us/mozilla/mozilla_bugs.htm [mccanless.us]

              so it is infact an OS vunerability and not browser specific. Infact, we have a patch and IE doesnt. That makes me feel good :)
          • Re:Bad way (Score:5, Insightful)

            by antiMStroll (664213) on Thursday July 08, 2004 @09:29PM (#9649139)
            " Which is basically to say:..

            Not at all. Mozilla falls down by trusting the multiple OSs it supports to securely handle something it doesn't understand. You did notice the part of the story that specifies this as a Mozilla/XP/2K exploit, right? No problem in Linux or *Bsd, etc., so I don't know how this OS intregration angle is relevant at all.

        • by Switchback (6988) on Thursday July 08, 2004 @07:04PM (#9648445)

          Agreed. It's not really a bug in the browser, it's a flaw in Windows.

          Windows has a bunch of protocol handlers registered. Mozilla knows how to handle a few (e.g. http, ftp, etc.). Whenever it encounters a protocol it doens't know what to do with, it sees if Windows knows how to handle it. Windows either handles it in some way or it doesn't. If it doesn't, Mozilla puts up a message saying "xyz is not a registered protocol." Mozilla has no way of knowing that anything is bad or dangerous.

          The real bug is in Windows. The only real options the Mozilla developers have is to black/white list known dangerous protocols or simply don't allow protocols Mozilla itself doesn't handle. Neither are optimal. If you can't trust the OS you're on, you really limit yourself, bugs or not.

          So we banish the "shell" protocol today. Who's to say Windows won't have another flaw in another protocol tomorrow?

          This really isn't any different than plugins, which are in a sense, external protocol handlers. i.e. they know how to handle certain content...just like a protocol handler. What if there is an exploit in a plugin? Mozilla just starts the plugin with the listed parameters and lets it go. Are you going to blame Mozilla for allowing the plugin to run, or are you going to require that Mozilla not allow "known, dangerous plugins" to run?

        • by dekeji (784080) on Friday July 09, 2004 @01:13AM (#9650031)
          Mozilla hands off schemes it doesn't know to the operating system (Windows), and WINDOWS executes the shell scheme

          The question remains: why does Mozilla "hand off" stuff from the Internet to the operating system? It obviously can't determine that doing so is safe, so it shouldn't do it.

          If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.

          Oh, nonsense. Mozilla doesn't run with "real restricted user accounts" on UNIX/Linux either. The responsibility of deciding what is trusted and what is safe to "hand off" to the OS rests firmly with applications on most modern operating systems; every application programmer should know that, and it is not hard to program accordingly.
      • by Anonymous Coward on Thursday July 08, 2004 @05:39PM (#9647797)
        Well, if you're going to brag about standards support, you need to support standards. Including the stupid ones.
    • Re:A clear advantage (Score:5, Informative)

      by Anonymous Coward on Thursday July 08, 2004 @05:29PM (#9647699)
      This incident underscores why many use or have switched to Firefox: vulnerabilities discovered and promptly fixed. Not weeks and months from their publication

      Yeah, it was years before it was addressed. If you read the Bugzilla report, it was first opened in 2002. This is not a good example of "open software fixes things faster".

      • Re:A clear advantage (Score:5, Informative)

        by SIGALRM (784769) * on Thursday July 08, 2004 @05:36PM (#9647771) Journal
        it was years before it was addressed
        Not really. The bug history began immediately afterward and for quite some time it was moved between FIX and WONTFIX but received a lot of attention. Here are some of the comments from the bug report at http://bugzilla.mozilla.org/show_bug.cgi?id=167475 :
        ------- Additional Comment #2 From Jesse Ruderman 2002-09-11 16:58 PDT [reply] -------
        It's not hard for a malicious site to get a visitor to click a link. Requiring
        a click or an equivalent keyboard action can be useful for limiting how much a
        web site can annoy you (pop-up windows, etc.) but I don't think it's useful for
        larger security issues.

        ------- Additional Comment #3 From Daniel Veditz 2002-09-11 17:25 PDT [reply] -------
        I agree, WONTFIX. Other bugs are already discussing blocking external protocol
        handlers, we don't need to do additional work to base the decision on context.

        ------- Additional Comment #5 From Daniel Veditz 2002-09-12 11:35 PDT [reply] -------
        re-opening for reconsideration. This doesn't solve the problem of untrusted
        protocols, but even for trusted ones it doesn't make much sense in these kinds
        of places.
        • by shellbeach (610559) on Thursday July 08, 2004 @06:13PM (#9648101)
          Not really. The bug history began immediately afterward and for quite some time it was moved between FIX and WONTFIX but received a lot of attention.

          However much developer attention it received (and actually it wasn't much - see my comments below), it doesn't change the fact that this exploit was present for almost two years ... and a fix was only released when the bug received wider internet attention.

          The speed with which a fix was issued after the general public was made aware of the problem was good ... but the previous activity over the bug (imagine setting the status to WONTFIX for this!!??) smacks of Microsoft-style negligence/lack-of-concern.

          The specific comments you cite are indicative of this lack of concern- Comment #2 basically claims that it's not worth fixing security issues that are initiated without any form of user intervention whatsoever. And why? because it's easy enough to get a luser to click on a malicious link, so why should we worry about sites that just bypass the malicious click?? I don't know about everyone else here, but that sort of logic concerns me!

          Just looking at the amount of interest in this bug after 2002 (only brief two comments in 2003 and another two in 2004; no patches submitted or even thought about) seems to suggest that if this had not been reported by the internet media this would never have been fixed. Or at least, not until exploits of it became commonplace.

          And with the recent internet-banking trojans using a similar exploit (i.e. download and run malicious code without any user prompting) in IE, the issue seems serious enough to me to have warranted a quicker fix.
          • Re:A clear advantage (Score:5, Informative)

            by shaitand (626655) * on Thursday July 08, 2004 @06:49PM (#9648345) Journal
            The debate on whether or not to do something about it was because it's the uri handler in the OS which is insecure, not mozilla.

            This isn't really a fix for a security problem in Mozilla, it's a workaround for a security problem in windows... which is why this only affects Mozilla on windows.
            • by shellbeach (610559) on Thursday July 08, 2004 @08:43PM (#9648937)
              This isn't really a fix for a security problem in Mozilla, it's a workaround for a security problem in windows...

              Well, regardless of the cause of the problem, if there's an exploitable hole it's still a security issue. Yes, it wasn't caused by some bad coding in Mozilla, but from reading the bug description and comments the exploit comes through HTML that has little or no valid use in legitimate, friendly web pages. (Hence it was possible for Mozilla to quickly release an all-blocking fix once it became publicised - disabling this funcitonality is not going to inconvenience anyone)

              In that situation, it still seems negligent to me when you're failing to fix an exploitable hole once it's come to your attention and when there's no disadvantage to doing so.

              As a very small-scale open-source developer myself, I feel that despite the GPL clauses about no warranty there's still something of a moral duty of care and trust in situations like this. Two years of being aware of this issue and doing little or nothing about it seems a bit worrying, IMO.
        • by johkir (716957) <jokirby AT vmth DOT ucdavis DOT edu> on Thursday July 08, 2004 @06:21PM (#9648147)
          Another big difference between the two is the fact that Mozilla even uses a publicly available bug list - Bugzilla. Theoreticaly, we all have a list of potential exploits at our finger tips. Could you imagine a list like that for IE? Maybe that's just what they need.

      • Re:A clear advantage (Score:5, Informative)

        by Anonymous Coward on Thursday July 08, 2004 @06:34PM (#9648238)
        The bug listed in the summary is about a general issue - no actual exploit was known. When an exploit was made known YESTERDAY, bug 250180 was filed, and fixed within 24hrs.

        Go to the source for better info!!!

        http://www.mozilla.org/security/shell.html
        • by jCaT (1320) on Thursday July 08, 2004 @08:01PM (#9648750)
          The bug listed in the summary is about a general issue - no actual exploit was known. When an exploit was made known YESTERDAY, bug 250180 was filed, and fixed within 24hrs.

          The longer known bugs are out there (and hell, even documented) the more time there is for someone to go out and actually write the exploit. Of course there won't be any exploits available when the bug is first found- unless the person who found the bug is the one who wrote the exploit (a rare case). I doubt in 2002 there was enough attention directed at mozilla to warrant a speedy bugfix, but since so many people are using it now it's under a lot more scrutiny. Now that mozilla is on the "radar" of crackers and other ne'er do wells out there, the exploits of known-but-not-fixed critical bugs are likely to start showing up more often.
      • Re:A clear advantage (Score:5, Informative)

        by mldl (779187) on Thursday July 08, 2004 @07:05PM (#9648458)

        Actually http://bugzilla.mozilla.org/show_bug.cgi?id=250180 is the first mention of the shell: bug. Bug 167475 is a catch all deciding whether or not Mozilla/Firefox should hand off unknown protocols. If it used a whitelist of known protocols as some people suggest then it would break a lot of things relied upon over various platforms.

        The specific shell: bug was reported only Wednesday morning which gives us a total time of less than 48 hours.

      • Re:A clear advantage (Score:5, Informative)

        by TRACK-YOUR-POSITION (553878) on Thursday July 08, 2004 @07:53PM (#9648710)
        Well, this is the bug you should probably be looking at: http://bugzilla.mozilla.org/show_bug.cgi?id=163648

        One of the comments explains why this "bug" is so long in being "fixed"--it was suggested that a dialog should be popped up before launching any external app, (which Internet Explorer only started to do sometime this year), but this is inconsistent--external plugins, like Flash, don't get similar dialog boxes in any browser, even though such plugins have been exploited in the past. Also, some programs launch their own dialog warning the user of executing from untrusted environments, and having Mozilla also display a warning is redundant. Essentially, any program that registers itself as a plugin or web protocol is saying "I will take care of the security issues involved with my execution." Therefore, while known dangerous protocols like vbscript were blacklisted (that's why this particular bug is FIXED, even though the comments suggest awareness of the current problem), they didn't implement a whitelist (which I guess is the plan for 1.0) or a dialog box (which Internet Explorer now relies upon, foolishly) because it was not consistent with the behavior towards external plugins.

        Presumably, with the bad press this has received, Mozilla has realized that Microsoft is going to put whatever-the-hell it wants to in as an external protocol, so unknown protocols should not be trusted. (Something that, apparently, Microsoft themselves has only realized in the last year or so.) shell: protocol is disabled in 0.9.2, and only whitelisted plugins will be trusted in 1.0. I think.

    • Re:A clear advantage (Score:5, Informative)

      by bwy (726112) on Thursday July 08, 2004 @05:31PM (#9647725)
      Very true- no software ever written has been 100% bug free. Mac, Linux, Mozilla etc. simply aren't targets for obvious reasons that are frequently brought up here.

      The difference in large part in my opinon boils down to:

      #1 WHO finds the bug. Is it the developers and community that discovers it in good faith, or is it a hacker and the rest of us find out after a billion dollars has been lost worldwide to the latest worm, virus, etc.

      #2 As you said, how quickly is the problem fixed. Certainly, private companies aren't necessarily horrible at doing this, to spite what people say. I work for a small software company and assure you that any security issues with our product would be corrected promptly. By the same token, some open source projects w/o a steady lead or direction could have exploits that go unfixed for some time.

      However, based on my observations and considering those two points, I'd say I certainly feel better using Firefox than IE.
      • by Wofser (794587) on Thursday July 08, 2004 @05:54PM (#9647955)
        "#1 WHO finds the bug. Is it the developers and community that discovers it in good faith, or is it a hacker and the rest of us find out after a billion dollars has been lost worldwide to the latest worm, virus, etc." The problem is not who find out about it. The problem is that a big portion of the users dont upgrade. I mean the latest 4-5 big worms did not use any unknown exploits. It used old and well documented exploits, exploits that you could find example-code for. Copy-paste-compile!!
        • Re:A clear advantage (Score:4, Interesting)

          by bwy (726112) on Thursday July 08, 2004 @06:06PM (#9648048)
          The problem is that a big portion of the users dont upgrade.

          One good thing, though. I've noticed a lot of larger companies are managing their desktops more tightly than they were a few years ago. Also shops running Citrix and Citrix-type environments have an advantage here... rather easy to make sure your users get the latest and greatest.

          Home users are largely a lost cause however. Your average Joe isn't going to go out downloading update patches. The Windows Update or Software Update (Mac) type things work pretty well but I'm just not sure how many users use them and they don't cover 3rd party apps.
    • Re:A clear advantage (Score:5, Interesting)

      by Anonymous Coward on Thursday July 08, 2004 @05:33PM (#9647747)
      Bullshit. The same e-Week article points to the Bugzilla discussion. Since Bugzilla refuses links from slashdot, I have copied the first post for bug 167475. Note the date and tell me about the "clear advantage".

      Opened: 2002-09-09 04:41 PDT

      As we can see in bug 163648, external protocols can cause a lot of security
      issues. But exploits for this bug are dangerous mainly if external protocol
      handler is being requested automatically from HTML code via <IMG
      SRC="externalprotocol:URL">, <IFRAME SRC="externalprotocol:URL"> and other
      similar cases.

      More, with relation to common sense, invoking an external protocol is absurd in
      this case, because <ANYTAG SRC="..."> is request to return some data in browser,
      not for launch external application.

      So, disable external protocols in all cases, excluding <A HREF=>, can solve this
      problem.

      Marking severity critical according to 163648.

    • by ron_ivi (607351) <[sdotno] [at] [cheapcomplexdevices.com]> on Thursday July 08, 2004 @05:48PM (#9647886)
      This incident underscores why many use or have switched to Firefox: vulnerabilities discovered and promptly fixed. Not weeks and months from their publication--and not by another vendor--....

      But some people [technewsworld.com] seem to be of the opinion that too many patches would be confusing.

      "Ballmer said one key improvement will be a simplification of the way patches are distributed. Microsoft plans to move to a monthly patch release schedule, which he said will make it easier for network administrators to plan updates, which often require system shutdowns before installation."
      If this other vendor is right that people want no more than monthly patches, such a fix may have to wait weeks.
  • by strictnein (318940) * <strictfoo-slashdot&yahoo,com> on Thursday July 08, 2004 @05:22PM (#9647625) Homepage Journal
    And now for some helpful links:

    Note: If you click on download links for firefox on the main page of mozilla.org [mozilla.org], you get 0.9.2 [mozilla.org]. The link on the firefox page @ http://www.mozilla.org/products/firefox/ [mozilla.org] still gets you 0.9.1 [mozilla.org]. The link on the main page for the Linux version of Firefox still points to version 0.9.1. It seems that if you want 0.9.2 for Linux you'll have to compile it yourself [mozilla.org].

    0.8 [mozilla.org]
    0.9rc [mozilla.org]
    0.9 [mozilla.org]
    0.9.1 [mozilla.org]
    0.9.2 [mozilla.org]

    And a direct link to the newest release for the really lazy:
    Windows 0.9.2 [mozilla.org]

    The question is, what is the shellblock.xpi [newaol.com] for?

    Does Bugzilla know? Sorry, links to Bugzilla from Slashdot are disabled. Ook!
  • Blast! (Score:4, Funny)

    by darth_MALL (657218) on Thursday July 08, 2004 @05:22PM (#9647633)
    "Note that this only affects users of Mozilla and Firefox on Windows XP or Windows 2000"...there goes a perfectly good Ha-Ha!. You've bested me this time *NIX...But you haven't seen the last of ME! BWAHAHA!
  • by homeobocks (744469) on Thursday July 08, 2004 @05:23PM (#9647637)
    I guess that this is a big deal because I can't remember the last time Mozilla had a remote hole in it.
  • by LostCluster (625375) * on Thursday July 08, 2004 @05:24PM (#9647646)
    I can't help but think that this thread from earlier today [slashdot.org] can be seen as good news from a security context...

    Just how does Mozilla/FireFox think it's going to keep malware from tricking the users into granting permission when the clueless masses come over from IE?
  • by GMFTatsujin (239569) on Thursday July 08, 2004 @05:26PM (#9647673) Homepage
    "Researchers are reporting another security issue in Web browsing under Windows"

    Sounds like a Windows problem, not a Mozilla problem. Oh, wait a minute...

    Current versions of Mozilla and Firefox pass unknown protocol handlers to the operating system shell to handle.

    Ding! Next. However:

    The attacker would have to know the location in the file system of the program

    So just in case, I'm renaming my /bin, /sbin, and /usr directories to /zurg, /mumph, and /splunge. Bring it, you haxx0rs!
  • Huh? (Score:5, Funny)

    by nettdata (88196) on Thursday July 08, 2004 @05:26PM (#9647674) Homepage
    malicious persons are much more unlikely to target any vulnerabilites

    I disagree... if anything, malicious people are MUCH more likely to target vulnerabilities.

  • by ZZeta (743322) on Thursday July 08, 2004 @05:29PM (#9647701)
    Of course bugs will appear in Firefox.
    Nobody in their right mind can expect a product to be perfect, but what makes Mozilla different is that bugs are fixed instantly. And that's because of the open source community, which is far more reliable than the competition.
    People might disagree with me, but I still think these bugs (and their immediate fixes) only show how great open source really is.
  • by Anonymous Coward on Thursday July 08, 2004 @05:30PM (#9647722)
    This is NOT a firefox bug. It is a bug in an external protocol in windows - of which Mozilla calls. The fix is to disable ALL external windows protocols. (bittorrent, mirc, etc)
  • by dicepackage (526497) * <dicepackage@nOSPaM.gmail.com> on Thursday July 08, 2004 @05:32PM (#9647739) Homepage
    How dangerous Mozilla can be. Everyone should be listening to Microsoft and use a secure browser such as Internet Explorer that isn't littered with security vulnerabilities.
  • Strange coincidence? (Score:3, Interesting)

    by hunterx11 (778171) <(moc.liamg) (ta) (11xretnuh)> on Thursday July 08, 2004 @05:35PM (#9647766) Homepage Journal
    Isn't this a bit like the bug that Safari (and OS X URI handling in general) had earlier? [slashdot.org]
  • Update system (Score:5, Insightful)

    by supercytro (527265) on Thursday July 08, 2004 @05:50PM (#9647915)
    Whilst it's easy to take pot-shots at Microsoft when it comes to IE, their update system isn't too bad. Firefox needs a easy to use mechanism for automatically retreiving and installing critical update, in a manner similar to MS windows update service.

    Even better, take a leaf out of Norton's liveupdate program.
  • Incorrect bug link (Score:5, Informative)

    by jesser (77961) on Thursday July 08, 2004 @05:51PM (#9647918) Homepage Journal
    Eweek and Slashdot linked to bug 167475, implying that Mozilla developers knew about this hole in 2002. Fixing bug 167475 would have done approximately nothing to protect Mozilla users against the shell: hole in Windows, and that is why bug 167475 hasn't been fixed.

    The correct bug number for this hole is bug 250180.
    • by DragonHawk (21256) on Thursday July 08, 2004 @08:33PM (#9648895) Homepage Journal
      The security exposure is apparently due to the fact that Mozilla, running on MS-Windows, will hand off any "URI scheme" Mozilla does not recognize to the OS. This only happens on MS-Windows. Since Windows may (and indeed, does, by default) know about URI schemes that do things you would not want a web page doing (like run programs), this is considered a problem for Mozilla.

      I have to agree that this is a Mozilla issue. To use a slightly contrived comparison: I read my mail using UW Pine. If someone sends me a script via attachment in email, I do not want Pine to test and see if the interpreter in the she-bang line is available on the host OS. My OS is not my mail reader; I do not want my mail reader allowing everything my OS can do. Ditto my web browser.

      There appear to be at least three Mozilla Bugzilla Bugs related to this (likely a lot more):

      #1 = Mozilla Bug 163767 (20 Aug 2002)
      "Pref to disable external protocol handlers"
      http://bugzilla.mozilla.org/show_bug.cg i?id=163767

      #2 = Mozilla Bug 167475 (9 Sep 2002)
      "Disable external protocol handlers in all cases, excluding <A HREF"
      http://bugzilla.mozilla.org/show_bug.cgi?id =167475

      #3 = Mozilla Bug 250180 (7 Jul 2004)
      "Shell: protocol allows access to local files"
      http://bugzilla.mozilla.org/show_bug.cgi?i d=250180

      It appears that Mozilla developers have been worried about this kind of problem going back to at least Aug 2002 (see #1 above). #1 talks about an option to disable external protocol handlers (URI schemes) by default. I have to say that would be the right thing to do. "Secure by default" is the correct approach.

      #2 talks about an approach that uses context to determine if an external handler should be invokved. Basically, it assumes that if a user clicked a link, they wanted to invoke the handler; anything that happened implictly (such as image loading) should not invoke an external handler. I do agree with those who commented (in that bug) that this is not the right approach. It adds complexity, and it still fails to address the fact that clicking a link is not something that should just up and run anything the web page wants. If I wanted that, I'd use MSIE.

      #3 is a reference to the "shell:" URI scheme in particular being abused this way. It blocks the "shell:" scheme to prevent that abuse. It does nothing to prevent abuses of other possible schemes, though. I suspect we may see this "feature" of Mozilla rear its ugly head again in the future.

      This is not a failure of Open Source in particular. Nor does it prove Mozilla is crap or Microsoft is okay after all. It means that people make mistakes. This should not surprise anyone. Stop pointing fingers and fix the problem.
  • Intentional (Score:5, Funny)

    by kyjello (566001) on Thursday July 08, 2004 @05:51PM (#9647925)
    This is added intentionally so that Mozilla contains all of the features of Internet Explorer.

    Oh yes, that's right! I went there.
  • by Temporal (96070) on Thursday July 08, 2004 @06:10PM (#9648076) Journal
    The developers considered changing from scheme blacklisting to whitelisting, in which case all schemes and protocols would be disallowed unless explicitly allowed.

    Duh.

    I have been saying this for some time now: Never use blacklists. Always use whitelists.

    If you forget to put an insecure operation on a security blacklist, you have a security hole. If you forget something on a whitelist, you just have an inconvenience.

    I am disappointed that the Mozilla developers did not have enough common sense to use whitelists in the first place. But then, it seems like most computer security schemes are blacklist-based, which explains why computers are so insecure.
    • by ZorbaTHut (126196) on Thursday July 08, 2004 @08:17PM (#9648817) Homepage
      Eww.

      One of the big disadvantages to the whole blacklist/whitelist things is, indeed, inconvenience. But you seem to be thinking it's just a minor inconvenience where, to a lot of people, it's major.

      Example: A while ago (I don't know if they still do, but it wouldn't surprise me) Unreal registered unreal:// to open games. You didn't have to do anything, it just worked. A lot of sites relied on this (click hyperlink, open unreal, badabing badaboom).

      Now, if the web browser used a whitelist, there's a few options. First off, it could be utterly impossible for Unreal to register even with user assistance - bzzt, this is bad. Remember, users want things to be easy.

      Second, it could require the user to go through the steps to add unreal:// to their settings. Also bad, because the Unreal coders don't want to have to change their installer every time the interface changes. Plus it's irritating for users. Bzzt.

      Third, it could ask the browser/OS to register itself, and the browser/OS could pop up a confirmation box. But we already know users can be duped into clicking just about anything ("You MUST click Yes for real 100% hardcore xxx porn!") and so this wouldn't exactly be a rock-hard barrier. Bzzt.

      Fourth, it can do what it does now, which is also flawed. Bzzt.

      I personally think solution 3 is the best one - but if Windows doesn't already have hooks for things like this, it might not be practical for Mozilla to add a happy little dialog. There might be a way to query the system about what it *would* do it if we happened to pass it an unreal:// url, then prompt the user to see if that's what they really want to happen, but I bet that's exploitable also ("What's this rundll thing? Oh, the line says 'free porn'! I'll click yes")

      I'd agree that more security = better (and more convenience = better too - the trick lies in balancing the two), but just saying "we should use a whitelist" leaves so much undecided that it's almost useless.
  • by klui (457783) on Thursday July 08, 2004 @06:32PM (#9648232)
    It's really not obvious when you go to Mozilla.org that there's a patch available. It should be on the right-hand-side instead of down in the middle of the page on the left-hand side. Also, mozilla.org/products/firefox doesn't tell you there's a patch available!! Hopefully, my email to its webmaster will help fix this soon.
  • by Rits (453723) on Thursday July 08, 2004 @06:56PM (#9648402)
    Opera long ago decided to *not* pass on any protocol or scheme to the operating system, except for a few well defined cases (ftp, telnet, mailto). Users of Opera 7 can add specific protocols/schemes manually in the prefs if they want.

    Lesson of today: there is always a danger in presenting yourself as 'the save alternative'. Proper engineering can reduce risks, but there are never garantees. Not that this example was especially worrying imho: you'd still have to be tricked to visit a specific website that plans to harm you. Not that likely unless you to tend to visit the bowels of the web...
  • Not only that, but it's a known (almost) ten year old bug in Windows - the use of the same set of handlers for local and remote services - and one I've been trying to tell people about for that long.

    Mozilla and Firefox should NOT be using this functionality, they should be doing ALL their own URL parsing and handling on Windows, Linux, Mac OS X, and so on, because they can *not* depend on the native OS to do security right.

    Even Apple doesn't do it right (see how they 'fixed' the help: problem), and Microsoft has refused to fix it on their side even under threat of judicial dismemberment.

    From the article:

    Is this really a security hole? When Mozilla receives a shell: request, it passes it on to an external handler in Windows. The "fix" for this is to disable this functionality which, as far as I can tell, is totally unnecessary to begin with. External handlers -- programs outside Mozilla -- have no specific security model, so the only way to deal with them is to make individual exceptions like this one. Messy? Yes. But that's Windows.

    The only way to deal with this is ONLY use external handlers you know are safe, rather than using all but the handlers you know have holes in them. Anything else is just following Microsoft's lead into a decade of virus-mania.
  • by MobyDisk (75490) on Thursday July 08, 2004 @08:29PM (#9648874) Homepage
    ...Is this really a security hole? When Mozilla receives a shell: request, it passes it on to an external handler in Windows. The "fix" for this is to disable this functionality...

    I am shocked that everyone here is sticking on Mozilla's side. I love Mozilla, and have used it since the beta versions. I install it on mom & pop computers all the time for security. But this is definitely Mozilla's fault. Mozilla should not pass unknown protocols to explorer. IMHO, that defeats the purpose of Mozilla. That would be like coding Mozilla to pass ActiveX controls to Internet Explorer since it doesn't support them.

    I treat Mozilla as a standalone app, and I consider that an advantage. I'm not vulnerable to scripting exploits, MS Office exploits, etc. But now I am told it passes some work to Explorer. I consider that a bug. I don't want it to pass everything except shell: to IE. I want it to pass nothing to IE.

  • by MichaelCrawford (610140) on Thursday July 08, 2004 @10:19PM (#9649377) Homepage Journal
    Having looked over the relevant bug reports, I'm extremely uncomfortable allowing mozilla to use ANY external protocols.

    Is there some way I can disable them all?

We will have solar energy as soon as the utility companies solve one technical problem -- how to run a sunbeam through a meter.

Working...