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."
Re:* Stops download of newest Firefox * (Score:5, Interesting)
NoScript (Score:5, Interesting)
yahoo or mozilla (Score:2, Interesting)
I sure hope it's only this version... (Score:2, Interesting)
Re:NoScript (Score:4, Interesting)
Re:* Stops download of newest Firefox * (Score:3, Interesting)
list of files that can be read (win32) (Score:2, Interesting)
or not
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.
Re:NoScript (Score:2, Interesting)
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.
Re:* Stops download of newest Firefox * (Score:5, Interesting)
Re:* Stops download of newest Firefox * (Score:3, Interesting)
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:Memory Usage / No Script (Score:3, 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.
--Joetired of these vulnerabilities which is why... (Score:1, Interesting)
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.
Re:NoScript (Score:5, Interesting)
The minority who can cope with those sort of settings can manage to install an extension.
Re:Firefox is too large to be secure (Score:1, Interesting)
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.
Re:NoScript (Score:2, Interesting)
Re:Firefox is too large to be secure (Score:1, Interesting)
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.