Forgot your password?
typodupeerror
Security Bug Mozilla The Internet

Serious Vulnerability In Firefox 2.0.0.12 355

Posted by kdawson
from the that-was-quick dept.
Oh, Not Now writes "Mozilla Firefox 2.0.0.12, mere hours old, is vulnerable by default to a directory traversal trick, via the view-source mechanism. Although mitigated by the NoScript plug-in, this is quite a serious bug — the default installation is vulnerable from the get-go."
This discussion has been archived. No new comments can be posted.

Serious Vulnerability In Firefox 2.0.0.12

Comments Filter:
  • Payload (Score:3, Informative)

    by milsoRgen (1016505) on Saturday February 09, 2008 @08:26PM (#22364748) Homepage
    So my I understanding is that this vulnerability can be used to read the host computer, and...

    Other issues can emerge also, this is only a short-hand proof of concept.
    I'm just curious if this could be eventually exploited to actually alter data on the affected host?
    • Why bother? If a script can read stuff (e.g. your Firefox password list, your cookies file) from the host computer and send it back to a remote machine, you're screwed.
  • NoScript (Score:5, Interesting)

    by bazald (886779) <bazald@@@zenipex...com> on Saturday February 09, 2008 @08:26PM (#22364756) Homepage
    Why isn't NoScript just a mandatory extension at this point? It seems like it would be pretty unobtrusive with default settings at a slightly reduced paranoia level.
    • Re:NoScript (Score:4, Interesting)

      by milsoRgen (1016505) on Saturday February 09, 2008 @08:31PM (#22364826) Homepage

      Why isn't NoScript just a mandatory extension at this point?
      I wouldn't be surprised if it becomes a part of the browser (or something like it), just as pop-up blockers of yore have been incorporated.
      • Re:NoScript (Score:5, Insightful)

        by mrsteveman1 (1010381) on Saturday February 09, 2008 @08:49PM (#22365008)
        If it became part of the browser, 3 things would happen: Idiots would scream and cry about being forced to use it, it would integrate better making it more effective, and vulnerabilities like the one referenced here would be a non-issue for a much larger percentage of the user base.

        Seriously, running every script a page stuffs into a browser should not be the default, and it should not take an extension to fix it.

    • Re:NoScript (Score:5, Insightful)

      by ilikepi314 (1217898) on Saturday February 09, 2008 @08:44PM (#22364958)
      Because most are not educated how to use it properly yet. It's terrific, but I know firsthand from trying to introduce it to people that they ignore it, realize many of their websites are broken, then I say "Well, you can allow certain websites you visit with this little button" -- they then promptly pick "Enable Globally" (or simply whitelist every single site they ever visit), and it has no effect.

      So instead of teaching people security, it just teaches them "Security is annoying and breaks everything, what's teh point?" and they want to use it less.
    • Re:NoScript (Score:5, Insightful)

      by Firehed (942385) on Saturday February 09, 2008 @08:48PM (#22364990) Homepage
      How would it work at a slightly reduced paranoia level? There are, I suppose, for options: block everything, block nothing, block off-site scripts, and only allow trusted scripts (somehow including a database of checksums of widely-deployed, known-safe scripts like Google Analytics' urchin, jquery, Amazon affiliate stuff, and... that's all that comes to mind). Foreign scripts aren't going to cause any damage unless the site itself is vulnerable to XSS attacks - malicious websites aren't likely to off-site the scripts. A database of the known acceptable scripts would be so minimal that it would defeat the point, especially as so few of them are of any benefit to the site visitor. Unless a built-in NoScript were to block specific functions in Javascript that could be used for malicious purposes (anything other than strict DOM manipulation, I suppose), it wouldn't do much good - and breaking half the JS on a site is probably going to be much worse than breaking everything.
      • Re:NoScript (Score:5, Interesting)

        by SJS (1851) on Saturday February 09, 2008 @10:06PM (#22365604) Homepage Journal

        ... (somehow including a database of checksums of widely-deployed, known-safe scripts like Google Analytics' urchin, jquery, Amazon affiliate stuff, and... that's all that comes to mind)

        Why is everyone in love with checksums?

        Disk is cheap. The amount of scripting I should trust is small.

        So cache the *actual* scripts... and then use those as keys into what scripts are actually run.

        That is, when you first hit a website that tries to run a script, capture all of the script functions and fragments, and indicate to the user how many un-approved scripts are on this page. The user than has the option to say "Trust this set of scripts" (like noscript now), or "Let me look at these scripts."

        And this is where the fun can begin.

        The browser can present to me a list of script functions and fragments, each with a "allow", "deny", or "remap" option. Allow is just that -- allow that script function or fragment to be run as-is, temporarily or for that page, machine, or domain. Deny is just that -- deny that script function or fragment, again, for that page, machine, or domain.

        For remap, however, I should get a little two-window/textarea display (top/bottom, left/right, don't care, should probably be the user's choice), one read-only (the key) and the other editable. I can then edit the second chunk of code as I please -- stupid client-side verification, gone, replaced with "return true;". Code that disables a feature, deletes information from the display, and so on and so forth... gone. The test for browser/os versions... gone. Bugs become fixable. (Sure, I might introduce bugs, but that's my own fault, and it's my browser anyway.)

        Most folks wouldn't ever use "remap" in this way, but that's okay. The ability is there, just like most folks don't compile open-source programs from scratch. That's not the point... if they wanted to, they could.

        The next step is to share remapping libraries, like people are sharing greasemonkey scripts now. I could get a call from my mother about how some website is broken to how she'd want to use it, and I can go look at the web-page, fix it, export my changes to some convenient archive, drop it on to my webpage, and then send the url to my mother, who can click on the archive, and have the browser ask "Do you want to install this?", click "Yes", and all is well in the world.

        Sure, some websites will take steps to make every bit of client-side scripting unique for every connection. They'll obfuscate their code, randomize the variable names on a per-session basis, mess with the structure... and now you KNOW those websites are hostile and malicious and should be treated as such.

        Don't bother with checksums, that doesn't put any power into the hands of the users. Track code, and allow for client-side replacement of code. Allow end-users to share their code-replacement libraries. We can kinda-sorta do that now with plugins and greasemonkey, but that's tricky and error-prone and tedious. Let the computer solve the problems that are tricky, or error-prone, and especially the problems that are tedious!

        • by GlobalEcho (26240) on Sunday February 10, 2008 @01:35AM (#22367032)

          The browser can present to me a list of script functions and fragments, each with a "allow", "deny", or "remap" option.
          What an amazing coincidence! My grandmother, my boss and my brother's girlfriend were all wishing out loud for that very feature just yesterday! We'll all be secure in no time!
    • Re:NoScript (Score:5, Insightful)

      by 93 Escort Wagon (326346) on Saturday February 09, 2008 @09:29PM (#22365320)

      Why isn't NoScript just a mandatory extension at this point? It seems like it would be pretty unobtrusive with default settings at a slightly reduced paranoia level.
      Well, to tech-savvy users this would be true; but unfortunately most users aren't even marginally tech savvy. It doesn't matter if NoScript puts up a clear, unambiguous giant flashing red sign that says "This site will have reduced functionality because we're blocking some scripts from running. Click here if you really want to run all these scripts" - based on past experience, most people will just be positively flummoxed and won't have the foggiest idea why some sites are now "broken".

      The thing is, looking at it from the designer/developer end, most users seem to want the functionality Javascript provides. My job largely consists of designing "intranet" apps for a university department. With forms, the end users want the ability to click a button or link to add extra fields when necessary. They want web-based calculators that figure out totals and percentages automatically. They like little explanatory pop-up boxes that define terms for them if they don't already understand what it means. They prefer drop-down menus that change, based on choices made further up the form.

      I realize that NoScript actually allows white-listing for situations like this (just like IE does for ActiveX, God bless 'em) - but I don't have much confidence that non-technical end users will understand, even with training. Making NoScript or a similar tool the default will end up meaning significantly more of my time being wasted dealing with support calls - after all, if the web's broken you don't call the desktop support people, you call the webmaster, right?

      (BTW is Firefox 3.0b2 or b3 vulnerable?)
      • Re: (Score:2, Insightful)

        by pipatron (966506)

        So because you decide to use the browser as some sort of generic code execution engine and GUI for your own hacks instead of writing your programs to run as a real application like everyone else, people browsing the web should remain a target for javascript abuse, bloat and exploits.

        I can't say I agree.

        • Re:NoScript (Score:5, Insightful)

          by 93 Escort Wagon (326346) on Saturday February 09, 2008 @10:47PM (#22365912)

          So because you decide to use the browser as some sort of generic code execution engine and GUI for your own hacks instead of writing your programs to run as a real application like everyone else, people browsing the web should remain a target for javascript abuse, bloat and exploits.

          It's not 1994 anymore. People don't just work on their own discrete data sets living on their own desktop computer now. People use webapps because the information is often centralized in places such as MySQL databases, and numerous different people need read and/or write access to it for differing reasons depending on their job function.

          The "real" applications (gotta love that required platform lock-in, btw) you talk about would still need access to that centralized data. So you pick your poison - do you provide direct access to that central data repository for a wide number of computers, or do you limit access just to connections from a web server (which is then open to that wide number of computers)? Personally I'd rather keep as much insulation as possible between that back-end data and the rest of the world.
    • Re: (Score:2, Interesting)

      by punissuer (1036512)
      Have you noticed how often NoScript gets updated? I wouldn't quite call it unobtrusive, especially since NoScript likes to make your browser open a tab to the NoScript site after an update. Really, how hard is it to prevent execution of javascript that didn't come from a site that's been whitelisted? I now use AdBlock Plus instead.
  • yahoo or mozilla (Score:2, Interesting)

    by erat123 (1114479)
    Maybe microsoft should have looked into mozilla instead of yahoo...
  • I've been using Iceweasl because the flash problems in Konquer were driving me nuts. You don't realize how much flash is on the web until it stops working.
    • Where do you have to go that needs flash? I specifically use 64-bit Epiphany without flash so I don't have that load for the minor benefits. It's cheifly used for advertising, as far as I have observed, and video. For video, it's not that hard to fire up 32-bit firefox with flash when I do want to watch them. Why do you need flash so?
      • Corporate sites (Score:4, Insightful)

        by Overzeetop (214511) on Saturday February 09, 2008 @09:05PM (#22365136) Journal
        There are quite a few corporate sites which incorporate flash to "enhance" their site, and there are some sites which won't even let you in unless you pass the flash-only home page. If you don't have flash, they don't want your business. (At least, that seem to be the opinion of the web IT staff, I haven't contacted corporate to see if they agree with that assessment). As for examples, Bath & Body Works used to be that way (I emailed them, they are no longer flash-limited...I don't believe those two things are linked, though). Rainforest Cafe is another. BBW didn't get my business back then, and Rainforest missed out on a dinner guest recently - I couldn't find their location, and couldn't use my mobile browser to get to their page. Will they care that they probably lost less than $100, of course not. But it certainly would have been nice if they wouldn't have had a "no flash, no service" sign out front.

        • by EtoilePB (1087031)
          But it certainly would have been nice if they wouldn't have had a "no flash, no service" sign out front.

          Yup. We all have Flash disabled and can't install it at work, because the overlord office in Europe doesn't understand that it's not just for YouTube. We're starting to have serious trouble using travel booking sites, hotel booking sites, and restaurant booking sites (all of which are legitimate and frequent uses of our PCs for our business) because of this. A HUGE percentage of them don't have a s
      • by gambolt (1146363)
        Unfortunately, too many sites use it for navigation and crap like that. The wire image viewers for most major newspapers use it. Embedded media in various blogs, etc.
    • by Kjella (173770)
      Well, bug and bug. Short story for those that don't know: Macromedia released a new version (r115) that relied on some functionality currently only in Firefox, but not in typical versions of Konqueror or release versions of Opera. This broke all the distros, including all old supported distros because Macromedia doesn't let repositories host old versions. Last I checked the possible solution was a big backport. Development versions of Konqueror (for hardy heron in my case) and Opera 9.5 supports it, but thi
  • Hopefully the Firefox 3 beta is not affected by this, that's what I've been running since Beta 2 came out. Anyone know?
  • by hcmtnbiker (925661) on Saturday February 09, 2008 @08:32PM (#22364834)

    That's right, back to the drawing board with this one. In the mean time you can either use another browser, or install the NoScript plugin to mitigate these issues.
    Or you can take the first step like you always should, and not visit sites you don't trust. Vulnerabilities always exist, betting that the developers will find them before someone else can exploit them is not a smart thing to do. Visiting only sites you trust will keep you away from people who want to compromise your computer 99.99999999% of the time, it really is the best thing you can do it terms of browser security.
  • nifty trick (Score:5, Informative)

    by Deanalator (806515) <pierce403@gmail.com> on Saturday February 09, 2008 @08:36PM (#22364874) Homepage
    It makes me happy that this type of vulnerability is what we call serious these days. If you remember, just a couple of years ago microsoft was downplaying the WMF vulnerability. It was not considered "critical" because the target needed to manually visit a malicious website for the attacker to take over the target machine.

    While this is a really neat find, and I am glad that it will be patched pretty soon, I don't think it is quite at the level of "sky falling" etc. From what I understand, an attacker that can execute javascript in your browser has the ability to read any file in the targets mozilla directory. This worst that I think an attacker could do would be to grab your stored password file. While this is definitely something to be concerned about, the headline had me pretty worried :-)
    • Re:nifty trick (Score:4, Informative)

      by Anonymous Coward on Saturday February 09, 2008 @10:43PM (#22365866)
      Actually they can't even get your stored passwords. They can only get files in "C:\Program Files\Mozilla Firefox\" which consists of nothing related to stored data, except for the greprefs folder, which isn't even YOUR preferences. From the looks of it, it's what a default Firefox profile gets stuck with. So, this is a pretty lame exploit, definately not serious, you can't access outside of the Mozilla Firefox directory from the looks of things.
  • saved passwords (Score:4, Insightful)

    by robo_mojo (997193) on Saturday February 09, 2008 @08:41PM (#22364924)
    Does anyone still think that it's a good idea to permanently store your passwords in your browser?
    • Yes, although only in conjunction with something like Firefox's master password to encrypt them.

      This brings up my greatest grip with Firefox: If you visit any site that you have stored a password for and you have a master password set, the damn thing pops open a request for any page that contains a password field. Take Slashdot or Digg, for example. If I'm browsing either of these sites almost every page I open requests a master password. You can turn off form auto-fill in about:config (not very end-user fr
      • Do you have a better way to store all your passwords?

        Try Secure Login [mozilla.org].
      • by Nazlfrag (1035012) on Saturday February 09, 2008 @09:37PM (#22365380) Journal
        There's this thing called carbon-based memory I use from time to time. Efficient, portable, unfortunately it is easily broken by Johnny Walker and co.
      • by QuickFox (311231)

        almost every page I open requests a master password.

        The first time you get this prompt, regardless whether you want to log in on that particular site or not, enter the master password. Once you've done that, the prompt won't pop up again during that session with Firefox. From that point on, all sites with a login will be filled out, but not submitted unless you click the login button on the web page.

        At least that's how it worked last time I checked (but that was some time ago).

        You should probably leave at least one Firefox window open all the time until you

  • The file they're reading from in TFA (all.js) contains a portion of the default Firefox preferences, not your current settings. There may be other ways to exploit this problem, and web pages definitely shouldn't be allowed to read any file from your computer, but the proof of concept isn't as bad as they say it is. The majority of your personal information is in your profile directory (under Application Data on Windows), not the program directory.
  • huh? (Score:5, Informative)

    by jelle (14827) on Saturday February 09, 2008 @09:12PM (#22365188) Homepage
    Doesn't look like a vulerability to me. So it can read files in /usr/lib/firefox, but those are just the standard files from the firefox package. User configuration and stored passwords etc are not stored there... It still can't get to $HOME/.mozilla...

    • Re: (Score:3, Insightful)

      by Shippy (123643)
      It's still a vulnerability. It's allowing something that shouldn't be allowed. Does that mean people will take advantage of it and exploit it a lot? Not necessarily, but it's still a vulnerability.
    • by jrumney (197329)

      It depends. Is the vulnerability in the view-source: method, or have the developers just not bothered to protect resource:/// since, as you say, it is all standard stuff that people can get by downloading firefox themselves? The way the exploit code has been posted, it is difficult to tell, because you need a javascript file that consists of lots of calls to a single function so you can override that function to print out the parameters instead.

  • by Anonymous Coward on Saturday February 09, 2008 @09:13PM (#22365198)
    I'm confused, how is this a serious security problem? All it allows is reading files from the Firefox application directory, which isn't exactly sensitive data, since you can get the exact same files from just downloading Firefox from Mozilla's website. Your prefs, passwords, etc. are stored in your Firefox profile, which lives outside the Firefox application directory, so they *are not* accessible via this trick.
  • Scare mongering (Score:5, Informative)

    by Anonymous Coward on Saturday February 09, 2008 @09:20PM (#22365246)
    gre is constant data. This report is FUD.

    Firefox is open source; anyone who wants to view view-source:resource:///greprefs/all.js can just as easily load http://mxr.mozilla.org/mozilla1.8/source/modules/libpref/src/init/all.js?raw=1 [mozilla.org] it has the same content.

    all.js is *not* user data, it's *public* app data. Your preferences are stored in prefs.js which are not exposed by greprefs.

  • by Anonymous Coward on Saturday February 09, 2008 @09:23PM (#22365272)
    Seriously, this title should be changed now (get rid of "Serious"), and a "!serious" tag added. The author of the article is an asshole who just waited for this release to fear monger and gain some attention. This bug exists in previous versions, this is not a new issue. The fact is, 2.0.0.12 fixes issues from previous issues, and does NOT introduce this "new" bug.

    You should still upgrade. You are already vulnerable to this "attack" without it, but you can at least gain some new fixes for other issues.

    You know, we're trying to promote open source software. To scream that firefox has a "serious vulnerability" when it in fact doesn't is IT treason.
  • Doesn't matter what browser you run, if you let anyone execute whatever code they want on your own machine via your browser it's the equivalent of running that trojan.exe you just downloaded from Messenger.

    Is there a NoScript for IE 7 and Opera?
    • by Petrushka (815171)

      Is there a NoScript for IE 7 and Opera?

      For IE7, I have no idea. I doubt it. In Opera, it's built in.

      (... BUT in Opera, enabling scripts for a specific site requires navigating through various sub-menus and five to eight mouse-clicks. And if the site uses cross-site scripting, as do most video sites for example, it could take anywhere up to a couple of minutes to investigate which sites you need to enable scripting for.)

  • How come? (Score:2, Insightful)

    by dreamchaser (49529)
    How come when there's a security hole in an MS product it gets the 'haha' tag, but if it's an OSS project it doesn't?
    • by shird (566377)
      Because one is by MS and the other by OSS. Slashdot users prefer OSS over MS so they laugh when there is a hole in a MS product, but are embarrassed by a hole in an OSS project.
    • by db32 (862117)
      I see the haha tag. Are you just upset that it didn't get the haha tag fast enough? Anyways, I don't think any vulnerability itself deserves 'haha' so much as the company that waves its hands and says "there is no bug here" or creates very bizarre ways of bug counting to get the numbers tell there story. On any given security issue if IE and Mozilla both had an identical issue and they were both identified at the same time, how long do you think it would take before Mozilla patched compared to IE?
    • Re: (Score:3, Funny)

      by jamesh (87723)
      If we could tag posts, yours would be tagged 'youmustbenewhere'.
  • by Anonymous Coward
    lol, serious stuff 300: file:///C:/Program%20Files/Mozilla%20Firefox/ 200: filename content-length last-modified file-type 201: .autoreg 0 Mon,%2005%20Nov%202007%2016:16:28%20GMT FILE 201: AccessibleMarshal.dll 13952 Fri,%2008%20Feb%202008%2019:42:30%20GMT FILE 201: LICENSE 30869 Thu,%2026%20Jul%202007%2002:39:20%20GMT FILE 201: README.txt 177 Thu,%2026%20Jul%202007%2002:39:20%20GMT FILE 201: browserconfig.properties 232 Thu,%2026%20Jul%202007%2002:39:26%20GMT FILE 201: chrome 0 Fri,%2008%20Feb%202008%2019
  • Something else weird that happened to me when I upgraded:

    I've got Firefox as my default browser on XP, and after the upgrade to 2.0.0.12, all of a sudden IE showed up as my browser at the top of my Start menu. When I went into the control panel to "set program access and defaults", Firefox doesn't even show up as an option. WTF?
    It's still installed, as it's in the programs folder, and it runs fine....also doesn't as me if I need to set it as default, so it still is, but Windows has completely lost the fac
  • by Morgaine (4316) on Saturday February 09, 2008 @09:52PM (#22365510)
    This isn't a problem just with Firefox, but with all full browsers today (the various midget text-mode ones excluded).

    Any non-trivial program contains bugs and vulnerabilities proportional to its size, and the relationship between size and inherent problem-count is probably a lot worse than linear. This is true for all programs and all systems, but it is especially true for monolithic ones, and to a very large extent the main body of modern browsers is quite monolithic. Even the plugins load into the same address space in most cases, although there are exceptions to this in the browser world.

    The present situation is not good, and everyone is familiar with the consequences of it: the web browser is by far the most crash-prone of all applications present in our operating systems today.

    Is there a solution to this on the horizon? Not at present, because developers in all the most popular programming languages almost always implement monolithic systems (because the languages encourage it and the courses teach it), and are highly adverse to extreme modularization. Again, there are exceptions, but they are rare.

    We are living in a bit of a Dark Age in this area currently, and I don't forsee any change within the next five years at least.
  • by enodo (603503) on Saturday February 09, 2008 @09:56PM (#22365538)

    If you take a look at what this is doing, there's much less to it than meets the eye.

    The way the page works is that it is able to load the file all.js in the greprefs directory inside your firefox installation. However, it is not *reading* this file and making it available to the javascript interpreter, it is *executing* the file. The file is a big list of browser preferences, each set with a call to a function with the signature pref(name, value). There is no code in there other than calls to pref. What the page does is define its own pref(name, value) which gets called, and the names and values are therefore available to the javascript interpreter.

    So:

    1. It has to know exactly what is in the file, and it has to be able to overwrite a function or functions so that some sort of privileged data becomes available to it. It has to be able to do this without the page throwing errors or halting execution. (That was easy with all.js, because the only thing in there was calls to pref. In other files I doubt it would be so easy.)
    2. As demonstrated, it can only read data that's inside the directory of the default install, not your home directory or anywhere else. As others have pointed out, it's not clear that there's ever anything really privileged in there for it to get. (The settings gotten in the exploit demonstrated are not very interesting.)

    I would additionally point out that the view-source: part of the URI appears to be unnecessary, since at least for me (Ubuntu FF 2.0.0.12) the "exploit" worked just fine without it.

  • by thethibs (882667) on Sunday February 10, 2008 @04:07PM (#22372310) Homepage

    Slashdot needs an implementation of Godwin's Law that shuts down a thread the first time Microsoft is mentioned and the topic is something that involves neither Microsoft nor any of its products.

    Thankfully, that would have put this thread out of our misery almost immediately, with no one any less informed as a result.

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Working...