Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Bug Mozilla The Internet

Serious Vulnerability In Firefox 2.0.0.12 355

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?
  • by De Lemming ( 227104 ) on Saturday February 09, 2008 @08:28PM (#22364796) Homepage
    As far as I understand, versions before 2.0.0.12 are also vulnerable...
  • by More_Cowbell ( 957742 ) * on Saturday February 09, 2008 @08:30PM (#22364808) Journal
    You don't run NoScript? Personally I'm using 3.0 beta2 (the few bugs are totally worth the better memory management, IMO), but I would never dream of running any version without NoScript.
  • by Beryllium Sphere(tm) ( 193358 ) on Saturday February 09, 2008 @08:34PM (#22364856) Journal
    >Visiting only sites you trust will keep you away from people who want to compromise your computer 99.99999999% of the time

    Assuming that the sites you trust haven't been compromised, this still leaves out the serious problem of attack code inserted into advertising.
  • 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 :-)
  • by FudRucker ( 866063 ) on Saturday February 09, 2008 @08:58PM (#22365082)
    Opera is closed source so you have no idea what vulnerabilities are in it...
  • What all.js contains (Score:2, Informative)

    by nonpareility ( 822891 ) on Saturday February 09, 2008 @09:02PM (#22365124)
    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...

  • 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.

  • Re:Damned it all (Score:5, Informative)

    by Nazlfrag ( 1035012 ) on Saturday February 09, 2008 @09:25PM (#22365284) Journal
  • Re:Fixed is hours! (Score:3, Informative)

    by DMoylan ( 65079 ) on Saturday February 09, 2008 @09:27PM (#22365306)
    > Everyone knows IE6 was horrible. I'm running IE7 under protected mode. If you're going to talk shit, at least talk shit about current software.

    well in their defence more people still use ie6. so they are talking about current software.

    http://www.w3schools.com/browsers/browsers_stats.asp [w3schools.com]

    at my job it is split about 90% ie6 v 10% ie7 for internet explorer users. thankfully the number of ie users is dropping as more switch to firefox. ie7 has speeded up that switch as many hate the interface.

    but to be on topic firefox has a serious bug. i expect it will be patched in a day or so. firefox is good at that.

    > Microsoft products are getting better.

    only because they have serious competition from firefox, apache etc.

    > Deal with it. Quit living in the past.

    i don't live in the past i use linux and mac osx.
  • by omeomi ( 675045 ) on Saturday February 09, 2008 @09:37PM (#22365378) Homepage
    Making it trim on minimize (something it should do by default) helped somewhat

    What you're describing has nothing to do with Firefox. Even if Firefox frees it's memory, that freed memory doesn't get reflected in the Task Manager until the program is minimized or you wait long enough...

    More info: http://www.garagegames.com/blogs/4517/11311 [garagegames.com]

    "The Windows OS employs something like a memory cache for each actively running program. This cache may grow as the needs of a particular program require using magical algorithms Microsoft developers have produced for determining the optimal size for that program. For instance a program over the course of it's life time may require 20 megs of memory but occasionally needs to load data requiring allocations of up to 10 additional megs which is released seconds after it is loaded and processed. The Windows OS may determine then, that the memory cache for this program must increase from the base 20 megs to 25 megs instead. Looking at the Windows Task Manager then, you may see that this program is now using 25 megs of memory, even though currently, it may only be using 20 megs.

    That is, the Windows Task Manager is reporting the memory cache allotment and not the memory allocated and used by the program. This is not the same as a memory leak. The program has little to no control over the memory cache allotment the OS has given it."
  • by Rakishi ( 759894 ) on Saturday February 09, 2008 @09:40PM (#22365398)
    Parent is an idiot or a troll, not informative.

    To quote the link itself, where it is written in large bold print right above what was quoted (emphasis mine):
    FIXED in Firefox 2.0.0.12
  • by tetromino ( 807969 ) on Saturday February 09, 2008 @09:42PM (#22365408)
    It looks like Firefox 3 Beta 2 is vulnerable. The proof of concept from the article works on FF3b2 on my machine (Linux i686).
  • by Vectronic ( 1221470 ) on Saturday February 09, 2008 @09:53PM (#22365518)
    You are right, my bad... I aparently skimmed over it too quick.

    the Giant 16point header of "Known Vulnerabilities in Mozilla Products" kinda made me think that they were infact "Known Vulnerabilities in Mozilla Products"...lol...

    However, depending on what angle you look at it from... *.12 could seems to either have more issues given that so many were fixed, OR... that the Mozilla team just didnt do much for the *.11 release.
  • 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.

  • DIRECTORY TRAVERSAL? (Score:5, Informative)

    by dominious ( 1077089 ) on Saturday February 09, 2008 @10:13PM (#22365658)
    Indeed,
    From TFA: "We can trick Firefox itself in traversing directories back".
    but then it says:
    "we are able to read out all preferences set in Firefox, or just open or include about every file stored in the Mozilla program files directory"

    Since TFA is not clear, I have tried it myself and I WAS NOT ABLE TO TRAVERSE a directory back with resource:///../
    So the only files someone can read with this vuln are the files inside firefox directory which from what I can see are just default files and no cookies or passwords.

    If anyone thinks any different please let me know.
  • Re:Damned it all (Score:2, Informative)

    by xSauronx ( 608805 ) <xsauronxdamnit@noSPAm.gmail.com> on Saturday February 09, 2008 @10:28PM (#22365756)
    ive been using noscript for months... great plugin, and one i wont go without.
  • 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.
  • by Symbolis ( 1157151 ) <symbolis&gmail,com> on Saturday February 09, 2008 @10:45PM (#22365898)

    On my box it's currently taking around 450MB. I usually kill it when it gets to around 700MB. Maybe it's because I use GMail and Yahoo! Mail open all the time?

    Madness.

    Mine's sitting at 68MB as I type this.

    No tweaking of any sort. Just now hit 70MB

    Run NoScript, too.

  • by Mr Z ( 6791 ) on Saturday February 09, 2008 @10:52PM (#22365952) Homepage Journal

    Well, I do have over 30 tabs open across 5 windows, and I leave it open 24/7.

  • Re:NoScript (Score:1, Informative)

    by Anonymous Coward on Saturday February 09, 2008 @11:29PM (#22366194)
    The fuck? You'd put Urchin on the whitelist?

    I mean, short of outright system-compromising code, that's like target #1 for blocking right there.
  • by nmb3000 ( 741169 ) on Saturday February 09, 2008 @11:29PM (#22366196) Journal
    Well it appears they are attacking an MS box, by the Program Files part of the filename string. I doubt this would do much on a *nix box with proper access permissions set up.

    Well then, let's see!

    C:\>cacls "Program Files"
    C:\Program Files
          BUILTIN\Users:R
          BUILTIN\Administrators:F

    root@box:/# ls -l
    drwxr-xr-x 2 root root 4096 Mar 19 2007 bin
    drwxr-xr-x 69 root root 8192 Dec 4 11:40 etc
    drwxr-xr-x 11 root root 80 Mar 19 2007 usr

    Hmm, look pretty similar to me. Maybe that because it makes no sense if normal users cannot read and execute applications and their associated data? Program Files on Windows being readable by everyone has nothing to do with what is a Firefox vulnerability.

    On the other hand I guess you're right. No "Program Files" directory on the Linux machine, it must be safe!
  • by Anonymous Coward on Sunday February 10, 2008 @12:38AM (#22366646)
    That's not X mapping your video card. The Firefox process is independent of the X server process.

    The first number is the virtual memory usage. The second number is the resident usage. What that means is that Firefox is in fact using nearly 1 GB of memory. However, about 500 MB of that has been paged out (ie. not stored in physical RAM, but on disk).

    That's a clear sign of a pretty serious memory leak. The fact that so much of that data is paged out shows that it's not being used frequently. More specifically, Firefox has lost track of the fact that it had allocated that memory at one point. Thus it's no longer used, but since it hasn't been returned to the OS, it's still taking up swap space, even if it luckily isn't wasting physical RAM.

  • by Anonymous Coward on Sunday February 10, 2008 @01:24AM (#22366958)
    It does not allow directory browse, it allows directory browse in
    C:\Program Files\Mozilla Firefox\...

    There is almost no data in there other than default settings.

    Your private settings and cookies are in the user directory
    C:\Documents And Settings\...

  • Re:Damned it all (Score:2, Informative)

    by captnjameskirk ( 599714 ) on Sunday February 10, 2008 @08:11AM (#22368718)
    They are written in Javascript but with special hooks that allow access to Firefox itself (e.g. creating new Firefox menu items, storing plugin settings between sessions, lots of stuff). The fact that the language is Javascript is not what causes the "bogging down", it's when a user installs many, many plugins. The same thing happens with IE when someone installs many, many toolbars or Browser Helper Objects. Don't overdo it and it's not a problem.
  • Not exactly.... (Score:5, Informative)

    by DrYak ( 748999 ) on Sunday February 10, 2008 @09:43AM (#22369126) Homepage

    Aren't Firefox plugins just Javascript?


    Depends.

    Firefox extensions (Like the oh-so-important NoScript [noscript.net] and AdBlock Plus [slashdot.org], or the must-have for every /.er Resurect pages [mozilla.org]) are all written in Javascript. That's what makes them portable (installable in Windows IA32 or AMD64, or Linux {whatever CPU you compiled it for}).

    On the other hand, web-browser plugins (like Adobe Macromedia Flash, Sun Java, etc.) are binary code in dynamically linked libraries (DLL or SO depending on what's standart on your OS). That's why there are really serious portability problems with closed source companies providing plugins compiled only for a handful of operating system (often without 64bits support).
    There are two strategies :
    - most of the time open-source projects use very light libraries which obtain the parameters from firefox and launch a player in a separate process that get its output embedded inside the page display (mplayer's plugin just luanch a sepparate mplayer session, gnash' plugin runs gtk-gnash to open the flash movie, webgcjplugin compiles and runs the java applet using gcj, moz-plugger is an universal embedder, etc...)
    - whereas most of the proprietary project try to cram everything inside a huge DLL that runs inside firefox' own process (macromedia flash, acrobat reader {BTW who does still use that piece of junk}, etc.)

    As I understand it, that's one of the major reasons that Firefox can get bogged down.


    The Javascript extensions play some role because the javascript engine of current Firefox isn't very fast (Hopefully the integration of Tamarin VM in some future version will help). If a user has way too many of them, the firefox experience can become slow. But most of the time quite, the extensions are event-driven : they usually add entries in the main menu and the javascripts are only executed when the user clicks the entry.

    The other problems comes with memory leaks.
    - Javascript extensions, because they are only ran on demand and because of the garbage collector, aren't subject to many leaks. But anyway really badly written code can actually degrade firefox performance and eat up memory.
    - Dynamically linked web browser plugins are a completely different animal : because they run inside the browser process (at least, not the open-source one which only launch an external process) if they leak memory, the whole firefox process will get its memory usage up and will only free the memory when the whole program is exited. Also, firefox isn't heavily multi-threaded and if some plugins freezes the whole program gets unresponsive (I've had some awful experience with acrobat and older versions of flash). Similarly crashes inside a dynamically linked library will bring down the whole process that called the function, and any exploit discovered inside flash can be used against firefox itself.

    I strongly suspect that most of the memory leaks reported by users are actually due to browser-plugins, because I haven't experienced any leaks even if a use several extensions, whereas I don't run closed proprietary browser plugins at all (mplayer and gnash only !) because of the awful experience with acrobat and flash.
  • by Foolhardy ( 664051 ) <[csmith32] [at] [gmail.com]> on Sunday February 10, 2008 @01:50PM (#22370998)
    Modern CPUs implement virtual memory, which means that any given page of memory (the smallest unit of allocation, per the CPU hardware) may not be directly accessible. The OS can decide to move a page to disk to make room for other things, or implement a memory-mapped file. When that page is accessed, it causes a page fault, which the OS silently fixes by moving the page back into memory. The memory currently accessible without causing a page fault and OS intervention is the working set. The amount of memory allocated (i.e. the amount of storage reserved by the OS), and the working set can be different.

    Linux implements a global working set. This means that when the OS decides that it wants to remove a page from its working set (i.e. swap it to disk), it pulls that page out of all the processes that are using it (since the page might be shared), writes it to disk and marks the page as free.

    Windows NT implements a per-process working set. A page is moved out of the working set of a particular process, and when it's been removed from all processes (in case it was shared), it goes into the standby cache, a sort of limbo where the page exists both in memory and disk and can't be written to (this makes it possible for the page to be moved completely to disk or back into use without further disk access). Each process has a soft minimum and maximum working set that the memory manager tries to keep a process within. Memory heavy processes have their max working set automatically expanded.

    "That is, the Windows Task Manager is reporting the memory cache allotment and not the memory allocated and used by the program. This is not the same as a memory leak. The program has little to no control over the memory cache allotment the OS has given it."
    Task Manager reports a process's current working set under the heading of mem usage. More pages allocated to the process may in fact be in memory in the standby list, but they won't show up in this count. Memory cached by the OS (e.g. standby cache, file cache, write cache) is not counted in the working set of any process, even if only one process is really using it. They show up as "System cache" in the performance tab, and some caches are double counted as "Available" because they can be discarded without disk access. When a process calls NtFreeVirtualMemory (the syscall for freeing private memory pages), the OS does not keep it in the process's working set. The working set is always equal or smaller than the sum of shared and private memory allocated to the process. If a process were to free all its private memory, and somehow unload all its modules and free its stack, the working set would go down to zero. A program has full control over what memory is allocated to it. It can't fully control how much of that memory is actually resident in RAM, though, and that's what is reported by Task Manager.

    When you minimize a window, the Win32 subsystem sets the process's maximum working set to the system minimum, effectively moving most of its private pages into standby. Those pages will only come back into the working set as they're accessed-- it may take a long time for the working set to get has high as it was previously, and possibly never for memory leaks or unused caches. Firefox definitely implements some hefty caches.

    In short: yes Windows implements a memory cache, but not for pages that have been freed.
  • 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.

  • by julesh ( 229690 ) on Monday February 11, 2008 @05:19AM (#22377228)

    It's slow,
    It's as fast as any browser I've used.
    You probably haven't tried using it on any machine older than about 2 years old. Firefox is quite unresponsive, particularly on javascript-intensive sites, compared to many other browsers, including Internet Explorer. Very long pages with lots of links cause it real trouble. Try this page [legislation.gov.uk]. On my system (2.66GHz Celeron D, 1GB RAM) there's a ~10 seconds pause after the page loads before I can scroll or switch tabs, and ~3 seconds between clicking on one of the links and the new page starting to load. IE6 handles it pefectly.

    I also don't think this is related to extensions. I'm not using anything unusual (popup alt attribute, tabbrowser prefs, flashblock, web developer).

    and it crashes
    I use Firefox quite extensively every single day for both business and personal uses and cannot recall it ever crashing. Not once, not ever. I've been using it since Firebird 0.6 and used many supposedly "unstable" nightly builds in earlier days. I trust it enough to use it during business presentations with clients rather than IE on which our applications have been most extensively tested.
    I've rarely had crashes until 2.0.0.11, but I've had about 3 over the last 3 weeks. I think there's something wrong with this build.

"Ninety percent of baseball is half mental." -- Yogi Berra

Working...