Slashdot Mirror

← Back to Stories (view on slashdot.org)

Serious Vulnerability In Firefox 2.0.0.12

Posted by kdawson on 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."

19 of 355 comments (clear)

  1. Re:* Stops download of newest Firefox * by webmaster404 · · Score: 5, Interesting

    Also, one thing that I have noticed about OSS bugs is that those severe enough to cause execution of code, there are very very few utilities to easily attack systems unlike their MS counterparts. Most OSS flaws are rarely exploited in the wild. The only thing that annoys me about them is that someone will surely come up to me on Monday stating how bad Firefox is because of this while blissfully ignoring all the flaws that Windows/IE has had for years.

    --
    There is no "disagree" moderation, and troll, flamebait and overrated are not valid substitutes
  2. NoScript by bazald · · Score: 5, Interesting

    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.

    --
    Insert self-referential sig here.
    1. Re:NoScript by milsoRgen · · Score: 3, Interesting

      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.
      --
      I'm sick of following my dreams. I'm just going to ask where they're goin' and hook up with 'em later.
    2. Re:NoScript by punissuer · · Score: 2, Interesting

      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.

    3. Re:NoScript by SJS · · Score: 4, Interesting

      ... (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!

      --
      Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
    4. Re:NoScript by the_womble · · Score: 4, Interesting

      Exactly, the average users reaction would be: Internet Explorer (or "the normal internet" as I recently heard it called) works on this site, Firefox does not, so Firefox is broken.

      The minority who can cope with those sort of settings can manage to install an extension.

    5. Re:NoScript by CNeb96 · · Score: 2, Interesting

      You forgot the 4th, it wouldn't be upgraded nearly as often as the current maintainers upgrade it. Noscript is updated all the time. Firefox needs a hybrid approach include extensions by default AND allow them to be independently updated separately from the main release, they don't do that currently for any extension.

  3. yahoo or mozilla by erat123 · · Score: 2, Interesting

    Maybe microsoft should have looked into mozilla instead of yahoo...

  4. I sure hope it's only this version... by WiglyWorm · · Score: 2, Interesting

    Hopefully the Firefox 3 beta is not affected by this, that's what I've been running since Beta 2 came out. Anyone know?

  5. Re:* Stops download of newest Firefox * by croddy · · Score: 2, Interesting

    Oh, you make a good point. I always wondered what people were talking about when they went on and on about Firefox consuming tons of memory because I would look at mine and it would never look even remotely like what people were describing. Of course, it all makes sense now -- less crappy unnecessary javascript running, fewer memory leaks. I can't imagine web browsing without manually whitelisting scripts either.

  6. list of files that can be read (win32) by Anonymous Coward · · Score: 2, Interesting

    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:42:39%20GMT DIRECTORY 201: components 0 Fri,%2008%20Feb%202008%2019:42:39%20GMT DIRECTORY 201: defaults 0 Fri,%2028%20Sep%202007%2022:59:30%20GMT DIRECTORY 201: dictionaries 0 Fri,%2028%20Sep%202007%2022:59:30%20GMT DIRECTORY 201: extensions 0 Fri,%2021%20Dec%202007%2011:21:24%20GMT DIRECTORY 201: firefox.exe 7655024 Fri,%2008%20Feb%202008%2019:42:35%20GMT FILE 201: freebl3.chk 476 Fri,%2008%20Feb%202008%2019:42:35%20GMT FILE 201: freebl3.dll 200829 Fri,%2008%20Feb%202008%2019:42:35%20GMT FILE 201: greprefs 0 Fri,%2008%20Feb%202008%2019:42:40%20GMT DIRECTORY 201: install.log 28197 Fri,%2021%20Dec%202007%2011:20:32%20GMT FILE 201: js3250.dll 456808 Fri,%2008%20Feb%202008%2019:42:35%20GMT FILE 201: nspr4.dll 161392 Fri,%2008%20Feb%202008%2019:42:35%20GMT FILE 201: nss3.dll 378472 Fri,%2008%20Feb%202008%2019:42:36%20GMT FILE 201: nssckbi.dll 271984 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: old-homepage-default.properties 112 Thu,%2026%20Jul%202007%2002:39:26%20GMT FILE 201: plc4.dll 34424 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: plds4.dll 30320 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: plugins 0 Fri,%2008%20Feb%202008%2019:42:42%20GMT DIRECTORY 201: res 0 Fri,%2028%20Sep%202007%2022:59:27%20GMT DIRECTORY 201: searchplugins 0 Fri,%2028%20Sep%202007%2022:59:30%20GMT DIRECTORY 201: smime3.dll 112232 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: softokn3.chk 476 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: softokn3.dll 254060 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: ssl3.dll 132712 Fri,%2008%20Feb%202008%2019:42:37%20GMT FILE 201: uninstall 0 Fri,%2008%20Feb%202008%2019:42:48%20GMT DIRECTORY 201: updater.exe 132232 Fri,%2008%20Feb%202008%2019:42:38%20GMT FILE 201: updater.ini 709 Fri,%2019%20Oct%202007%2013:36:24%20GMT FILE 201: xpcom.dll 13416 Fri,%2008%20Feb%202008%2019:42:39%20GMT FILE 201: xpcom_compat.dll 73848 Fri,%2008%20Feb%202008%2019:42:38%20GMT FILE 201: xpcom_core.dll 422000 Fri,%2008%20Feb%202008%2019:42:39%20GMT FILE 201: xpicleanup.exe 73336 Fri,%2008%20Feb%202008%2019:42:39%20GMT FILE 201: xpistub.dll 12400 Fri,%2008%20Feb%202008%2019:42:39%20GMT FILE

    or not

  7. Re:or just visit sites you trust by 11223 · · Score: 4, Interesting

    Or you can take the first step like you always should, and not visit sites you don't trust.


    Ever use an open 802.11 access point? Ever been redirected to a legalese page before being allowed onto the internet? Now what if that page had the exploit in it? For added fun, imagine the hotspot isn't malicious but there's an attacker on the network using a rogue DHCP server to feed you a bogus set of DNS servers.

    People assume that their web browser is a trusted execution environment. Vulnerabilities which affect the browser are worth caring about for that reason.
  8. Firefox is too large to be secure by Morgaine · · Score: 4, Interesting

    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.

    --
    "The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
    1. Re:Firefox is too large to be secure by Anonymous Coward · · Score: 1, Interesting

      Firefox isn't modular at all. OK, someone else already pointed that out. What they neglected to mention was that all those extensions and themes and everything just dump all their crap into who gigantic global namespace.

      At its core, Firefox is a JavaScript application. Yes, really. XUL, which creates all the UI in Firefox, works like a sort of specialized HTML for GUIs. If you've worked with CSS, HTML, and JavaScript, you'll be able to pick up XUL really fast. (This is an oversimplification, but it gets the idea across. OK, pedants?)

      In any case, each Firefox window acts just like a webpage - it contains a "window" object, a single DOM, and a single JavaScript namespace. Extensions add to the default XUL documents using a special XML patch language that Mozilla calls an "overlay" - but it's really a patch. Each extension alters the XML DOM and adds its functions straight into the single JavaScript namespace.

      The end result? Firefox is a giant ball of mud. What can be called modules wind up being dumped into a giant blob. The parts that are written in pure JavaScript have no data hiding since JavaScript doesn't support that. (The exception being XPCOM objects written in JavaScript, with the exception to the exception being that there's some magic that can be done to get past that restriction.)

      After having played around with writing Firefox extensions, it always amazes me that the browser works at all. Its internals are amazingly fragile.

    2. Re:Firefox is too large to be secure by Anonymous Coward · · Score: 1, Interesting

      At the core, literally, Firefox is C++. In much the same way that, at the core, Java programs literally run using native code? It's technically true, but entirely irrelevant.

      In that way, Firefox is modular, not monolithic, as the XUL interface and C++ core are obviously two different parts. That doesn't follow. Linux doesn't suddenly become a microkernel just because it supports dynamic module loading, and Firefox doesn't magically become modular just because the core is written in C++.

      Other Mozilla browsers, such as SeaMonkey, can change the user interface while using the same core. Right - making Firefox a JavaScript application built on top of the Mozilla core. Just like SeaMonkey is a JavaScript application built on top of the Mozilla core and Thunderbird is a JavaScript application built on top of the Mozilla core.

      The parts that make Firefox what it is are all written in JavaScript, and this JavaScript forms a giant blob of code that all interacts in a single namespace. Just because it's object oriented doesn't make it modular.
  9. Re:* Stops download of newest Firefox * by Achromatic1978 · · Score: 4, Interesting

    So, it's their fault, right? Funny, just reading their page alone mentioned how they'd already made mention of how this affects more than just extensions, but Mozilla ("What leaks? Show us a single leak!") developers shrugged, blamed extensions, and released, without fixing the core problem.

  10. Re:* Stops download of newest Firefox * by Compholio · · Score: 2, Interesting

    who really cares, I am gonna use firefox, not to many hackers are that good at getting into Linux Machines, and if I wasn't gonna use FireFox then I would use Opera. Cheers!
    Yeah, plus (according to TFA) all they can do is traverse the install folder. Said hacker can have fun looking at all the plugins and blank password database in my ~/.mozilla/firefox/ folder all they want.
  11. Re:Memory Usage / No Script by Mr+Z · · Score: 2, Interesting

    How many windows / tabs do you tend to have open, and how often do you restart the browser? Also, what OS?

    Here's the output of ps on my 64-bit Ubuntu 7.04 box, running Ubuntu's Firefox package:

    im14u2c 2527 6.1 11.2 987640 454116 ? Sl Feb07 176:30 /usr/lib/firefox/firefox-bin

    The first number suggests Firefox is taking nearly 1GB, but 512MB of that is just the X mapping my video card, I think. The second number shows it clearly taking around 450M.

    --Joe
    --
    Program Intellivision!
  12. tired of these vulnerabilities which is why... by Anonymous Coward · · Score: 1, Interesting

    I run my Firefoxes (yup, with "es" ;) in special user accounts, made especially for surfing. My main Firefox (the one I use the most) is run as a user that does nothing else than browsing. Sure, it's a little cumbersome when I d/l files that I need to move to my real account, but I'm running Firefox like that since years and I can't stop LMAO'ing when I read about another yet Firefox vulnerability. Then I've got another special user account, only for another Firefox, to do my GMail/PC Banking. These two Firefox instances are always on, each on a virtual desktop.

    Some even go the 'virtual-machine-only-for-browsing' way and I may do that soon (probably using KVM). I know, I know, "virtual machines" perfs sucks (so you think).

    So, yup, a nasty person using a Firefox vulnerability could read every single file in Firefox's directory (and subdir), that's what the exploit referred to in TFB (the f*cking blog?) talks about or it could read every single file belonging to the user running the browser: no big deal, that's exactly my point.