Slashdot Log In
Serious Vulnerability In Firefox 2.0.0.12
Posted by
kdawson
on Saturday February 09, @07:20PM
from the that-was-quick dept.
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."
Related Stories
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
NoScript (Score:5, Interesting)
Re:NoScript (Score:5, Insightful)
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)
Re:NoScript (Score:5, Interesting)
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!
Re:NoScript (Score:5, Insightful)
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 (Score:5, Insightful)
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, Funny)
nifty trick (Score:5, Informative)
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? (Score:5, Informative)
Scare mongering (Score:5, Informative)
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.
Update the title... NOW. (Score:5, Insightful)
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.
Firefox is too large to be secure (Score:5, Interesting)
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.
This bug is less important than it seems (Score:5, Informative)
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:
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.
Damned it all (Score:5, Insightful)
Oh, well, just one more unlocked door in the grass hut I call a computer.
Re:Damned it all (Score:5, Informative)
Re:* Stops download of newest Firefox * (Score:5, Interesting)
Re:* Stops download of newest Firefox * (Score:5, Informative)
Re:* Stops download of newest Firefox * (Score:5, Insightful)
Re:* Stops download of newest Firefox * (Score:5, Interesting)
Re:* Stops download of newest Firefox * (Score:5, Insightful)
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
Re:* Stops download of newest Firefox * (Score:5, 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
Re:* Stops download of newest Firefox * (Score:5, Informative)
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."
Re:or just visit sites you trust (Score:5, Informative)
Assuming that the sites you trust haven't been compromised, this still leaves out the serious problem of attack code inserted into advertising.
Re:or just visit sites you trust (Score:5, Interesting)
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.
DIRECTORY TRAVERSAL? (Score:5, Informative)
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.