Serious Vulnerability In Firefox 2.0.0.12

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

Comments

Re:* Stops download of newest Firefox *

[webmaster404]

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.

NoScript

[bazald]

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

[ilikepi314]

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

[Firehed]

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

[mrsteveman1]

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

[93 Escort Wagon]

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:NoScript

[93 Escort Wagon]

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:* Stops download of newest Firefox *

[LiquidCoooled]

Why stop downloading it?
I cannot work out from the article whether older versions of Firefox are vulnerable or not.
If its an unfixed bug from previous versions you should continue to download.
Which would you rather:
have 20 known vulns in the wild (stay as you are),
have 1 known vuln wild (latest update).

Until we can be certain though, just click pause ;)

nifty trick

[Deanalator]

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 :-)

huh?

[jelle]

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

Scare mongering

[Anonymous Coward]

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

Update the title... NOW.

[Anonymous Coward]

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.

Re:Damned it all

[Nazlfrag]

http://noscript.net/getit.

Re:* Stops download of newest Firefox *

[Rakishi]

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

This bug is less important than it seems

[enodo]

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?

[dominious]

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.

Not exactly....

[DrYak]

Aren't Firefox plugins just Javascript?

Depends.

Firefox extensions (Like the oh-so-important NoScript and AdBlock Plus, or the must-have for every /.er Resurect pages) 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.