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

7 of 355 comments (clear)

  1. Re:* Stops download of newest Firefox * by webmaster404 · · Score: 5, Interesting

    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
  2. NoScript by bazald · · Score: 5, Interesting

    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.
    1. Re:NoScript by SJS · · Score: 4, Interesting

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

      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!

      --
      Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
    2. Re:NoScript by the_womble · · Score: 4, Interesting

      Exactly, the average users reaction would be: Internet Explorer (or "the normal internet" as I recently heard it called) works on this site, Firefox does not, so Firefox is broken.

      The minority who can cope with those sort of settings can manage to install an extension.

  3. Re:or just visit sites you trust by 11223 · · Score: 4, Interesting

    Or you can take the first step like you always should, and not visit sites you don't trust.


    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.
  4. Firefox is too large to be secure by Morgaine · · Score: 4, Interesting

    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
  5. Re:* Stops download of newest Firefox * by Achromatic1978 · · Score: 4, Interesting

    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.