Slashdot Mirror
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."
Just before I opened this session, I had upgraded.
Oh, well, just one more unlocked door in the grass hut I call a computer.
Is it just my observation, or are there way too many stupid people in the world?
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
I'm sick of following my dreams. I'm just going to ask where they're goin' and hook up with 'em later.
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.
As far as I understand, versions before 2.0.0.12 are also vulnerable...
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
liqbase
If i had one dollar for every brain you dont have, i would have $1.
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
But but.....don't many eyeballs watch the mozilla codebase?
You gotta love Firefox apologists. They can turn a complete failure on behalf of Firefox development and release engineering into a discussion about how Microsoft is horrible and IE fails.
You're living in the past. 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. People who spend their time talking about how Windows 98 crashed a lot, IE5 and 6 were really insecure, and IIS 5 was the fastest way for a computer to get hacked on the net, are really starting to sound tired and sad. When we're running Windows 7, Internet Explorer 8.0 in Protected Mode, and IIS 7.0 on Windows Server 2008, fools like you are still going to be apologizing for every bug in by bringing up bugs from Microsoft products 5+ years ago.
And even if IE6 was the most horrible browser ever and they waited for "moths if not years" for patches, how does that make this Firefox vulnerability any better? If IE6 is so bad, why is it your example for trying to minimize this Firefox vulnerability?
Microsoft products are getting better. Deal with it. Quit living in the past.
Does anyone still think that it's a good idea to permanently store your passwords in your browser?
Sure, and some of those eyeballs wait until just after the release of a new version to announce they know of a security vulnerability just to draw attention to themselves. Open source does help security bugs to be found, but it doesn't magically keep the finders from blabbing to all hackers worldwide exactly what the problem is and how to exploit it.
What a fool believes, he sees, no wise man has the power to reason away.
Opera is closed source so you have no idea what vulnerabilities are in it...
Politics is Treachery, Religion is Brainwashing
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.
Is it just my observation, or are there way too many stupid people in the world?
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...
--- Hindsight is 20/20, but walking backwards is not the answer.
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.
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.
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.
As someone who uses Linux because I was able to customise it to be exactly compatible with the way I think, and so I'm unable to run Internet Explorer or IIS, I have to say you make an excellent point.
To everyone else: Do you remember before the browser wars, when Netscape was the big, bloated dominant player and Internet Explorer was the fast and light competitor which needed to prove itself (even if it did so by cheating)? Do you remember the time between the wars, when Internet Explorer was buggy and insecure? Now we are in the second browser wars and Internet Explorer is trying to compete. And it's a good thing. The Mozilla foundation cannot afford to sit on their laurels or Firefox will be the also-ran that the Mozilla suite is. Never hold yourself to someone else's standards: Be the very best you can be, and it'll always be better.
And be grateful for it — we on Linux pretty much have no choice but Firefox (or Firefox-based browsers) if we want a vaguely native, somewhat integrated system (well, there's Konqueror if you use KDE but it's not up to the same level as Firefox and Internet Explorer). There's no competition, no choice, and no reason for Mozilla to focus their development effort over on this side of the fence. And we suffer for it, with form widgets that don't look right and menus that don't work properly.
Look out!
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
"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."
ZuluPad, the wiki notepad on crack
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
It looks like Firefox 3 Beta 2 is vulnerable. The proof of concept from the article works on FF3b2 on my machine (Linux i686).
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
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.
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.
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.
Let me get this straight: do you honestly think that something being Open Source will magically protect you? I was going to mod you but there's no "-1 Naive".
There are enough malware targeted specifically at Firefox - I've seen them in action. The good thing with Firefox is that it gets patched pretty quickly, by the time an exploit has been written, hopefully we'll all have 2.0.13 installed.
Still, that's no excuse. It saddens me to say that the quality of Firefox (2.x.x branch) is steadily declining. It's slow, eating too many resources, and it crashes - on some sites it just constantly crashes. If it weren't for all the extensions, I'd dump it in a heartbeat and move to Opera.
Depends.
Firefox extensions (Like the oh-so-important NoScript and AdBlock Plus, or the must-have for every
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.)
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]