Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Mozilla The Internet Security

New Firefox Vulnerability Revealed 250

Posted by Soulskill from the whack-a-fox dept.
Not long after Firefox 3.5.1 was released to address a security issue, a new exploit has been found and a proof of concept has been posted. "The vulnerability is a remote stack-based buffer-overflow, triggered by sending an overly long string of Unicode data to the document.write method. If exploited, the resulting overflow could lead to code execution, or if the exploit attempts fail, a denial-of-service scenario." It's recommended that Firefox users disable Javascript until the issue is patched, though add-ons like NoScript should do the trick as well (unless a site on your whitelist becomes compromised).

Update: 07/20 00:09 GMT by KD : An anonymous reader informs us that the Mozilla security blog is indicating that this vulnerability is not exploitable; denial of service is as bad as it gets.
This discussion has been archived. No new comments can be posted.

New Firefox Vulnerability Revealed More

New Firefox Vulnerability Revealed

Comments Filter:

  • Unbounded (Score:5, Funny)

    by Mikkeles ( 698461 ) on Sunday July 19, 2009 @12:19PM (#28748531)

    So who's the moron using unbounded buffers?

  • That a remote stack-based buffer-overflow can be triggered to compromise FF.
    But why on earth those friendly developers don't design, implement a damned solution to be used everywhere in the code???
    Fix once, fix forever (until next smarter exploit).

    • Re:That's notthe first time (Score:5, Informative)

      by BZ ( 40346 ) on Sunday July 19, 2009 @01:01PM (#28748803)

      Have you tried the POC? Ideally under a debugger? It's a null-dereference crash due to failure to check an allocation for out-of-memory conditions. It's not exploitable, as far as I can see. And it's not a stack buffer overflow, by any means.

      It'd be nice if these various security advisory services actually double-checked milw0rm postings before echoing them. Half the ones I've seen are in fact crashes, but not the sort the poster claims and not exploitable....

      • Re: (Score:3, Informative)

        by Inda ( 580031 )

        Worse POC evar

        -----

        <html>
        <head>
        <script language="JavaScript" type="Text/Javascript">
        var str = unescape("%u4141%u4141");
        var str2 = unescape("%u0000%u0000");
        var finalstr2 = mul8(str2, 49000000);
        var finalstr = mul8(str, 21000000);


        document.write(finalstr2);
        document.write(finalstr);

        function mul8 (str, num) {
        var i = Math.ceil(Math.log(num) / Math.LN2),
        res = str;
        do {
        res += res;
        } while (0 < --i);
        return res.slice(0, str.

        • Re: (Score:2)

          by BZ ( 40346 )

          Well... That code _does_ crash the browser. Just not exploitably. ;)

        • Running this in Swiftfox 3.5.1 makes it eat all your RAM.

          Ditto Opera 10. I had to kill Opera 10 though, I could close Swiftfox.

    • Re:That's notthe first time (Score:4, Interesting)

      by ciroknight ( 601098 ) on Sunday July 19, 2009 @01:11PM (#28748865)

      Fix once, fix forever

      The bug is in the Just-in-Time compiler inside of SpiderMonkey (TraceMonkey). This is brand new code as of 3.5.x. Of course there will be a ton of bugs found in it (just like the ton of bugs that have cropped up in SquirrelFish and have been subsequently patched).

      I have to wonder why it's taken so long for anybody's security team to look at this code though. You'd think they'd look at this code before release and not after.

      • Fix once, fix forever

        The bug is in the Just-in-Time compiler inside of SpiderMonkey (TraceMonkey). This is brand new code as of 3.5.x. Of course there will be a ton of bugs found in it (just like the ton of bugs that have cropped up in SquirrelFish and have been subsequently patched). I have to wonder why it's taken so long for anybody's security team to look at this code though. You'd think they'd look at this code before release and not after.

        I think the point is that there are auditing tools which can automatically detect this kind of buffer overflow in source code. There are also libraries which offer versions of various functions that automatically include bounds checking that can help to prevent this kind of buffer overflow. You'd think that basic fuzz testing might find it as well. So far as I know, no such tools were used. New code or old code should not meaningfully change this scenario because new code need not be released and versio

        • Re: (Score:2, Interesting)

          by e9th ( 652576 )
          Remember the Debian SSH debacle? [slashdot.org] Some guy wanted to stop valgrind's whining about uninitialized memory in the SSL key generator, so he helpfully zeroed the buffer in question. Valgrind stopped complaining, but his fix also reduced the entropy used in key generation down to about nothing. For two years, people were generating very weak key-pairs.

          I'm not saying valgrind, etc. are bad, only that sometimes they can be misleading.

  • Turn off javascript... (Score:5, Insightful)

    by popo ( 107611 ) on Sunday July 19, 2009 @12:25PM (#28748579) Homepage

    ... and stop using all of your web-apps... sigh...

  • You can't be serious! (Score:4, Insightful)

    by jeffliott ( 1558799 ) on Sunday July 19, 2009 @12:26PM (#28748581)

    I don't know anything about JavaScript or Firefox internals, but a public sounding central function call like "DOCUMENT.WRITE" having a length related buffer overflow is just unacceptable. This call is used all the time right? How could this be missed?

    • Re: (Score:3, Insightful)

      by TopSpin ( 753 ) *

      This is my feeling as well. FYI: document.write is the JavaScript equivalent of write(2). It is used liberally in modern web content; I doubt there are any popular contemporary pages that don't use it.

      This code path should be impervious to any overflow exploit that might conceivably appear. Obviously document.write can and is used to exploit other more subtle flaws in a browser as it is capable of producing arbitrary document content, but that's not what we have here. Here we have long strings breaking

      • FYI: document.write is the JavaScript equivalent of write(2). It is used liberally in modern web content; I doubt there are any popular contemporary pages that don't use it.

        Aside from ads (where document.write() is relatively common), use of document.write is quite rare. The main reason is that document.write is largely useless after the page has loaded.

        Perhaps you're thinking of elem.innerHTML? The use of which is extremely common.

      • About the only place this is used is to inject ads, and tracking for 3rd party servers. Very few sits use this technique internally. Most modern development uses avstraction libraries which inject DOM nodes, or use innerHTML for post-render injection. it's actually pretty bad-form to rely on inline document.write functionality because of browser behavior.

    • Re:You can't be serious! (Score:5, Informative)

      by BZ ( 40346 ) on Sunday July 19, 2009 @01:05PM (#28748833)

      It's not a buffer overflow. It's a missing OOM check leading to a non-exploitable (well, if your kernel is sane; some Linux versions are not) null-dereference crash.

      Note also that the article linked to is misreporting this in other ways as well; unfortunately I'm not at liberty to go into details on that yet. :(

      • Not at liberty? Isn't Firefox open source?

        • Re: (Score:2)

          by BZ ( 40346 )

          Yes, it is. That's not related to the issue at hand.

        • Re: (Score:2)

          by dkf ( 304284 )

          Not at liberty? Isn't Firefox open source?

          He may have voluntarily agreed to hold off discussing a related known problem until it is fixed. I've done that a few times for other software (no, I don't feel like telling you what even though the fixes have been done for many years now) and with responsive OSS projects - either because they've got someone who really cares about this sort of thing, or because they've got lots of effort anyway - such issues tend to get fixed very rapidly. To be fair, that's true of the good commercial developers too; nobod

    • Re:You can't be serious! (Score:5, Informative)

      by BZ ( 40346 ) on Sunday July 19, 2009 @02:16PM (#28749279)

      Ok, here's the full deal:

      1) The crash is not exploitable, for anyone who's been able to reproduce it so far.
      2) The crash is in system text-rendering libraries (which apparently don't check for
            out-of-memory much), not in Firefox code, for everyone who's been able to
            reproduce it so far.

  • Many eyes makes for secure code (Score:4, Insightful)

    by nacturation ( 646836 ) * <nacturation&gmail,com> on Sunday July 19, 2009 @12:26PM (#28748583) Journal

    Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.

    • Re: (Score:3, Interesting)

      by dougisfunny ( 1200171 )

      Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.

      Except that other people are a lot more likely to find the same bug, and report it regardless of the black hats.

    • After all, FF is open during development, not just after release. 3.5 has been a long time in coming, the code has been out there for lots to see and lots have looked, yet this was missed.

      The thing is, open or closed, any major project has a lot of people looking at the code, and at least some of those people, perhaps most, are highly skilled. What this means is that it isn't likely there's an extremely obvious bug in the code. It isn't the sort of thing that someone would look at the source and go "Oh look

  • failed proof of concept (Score:3, Informative)

    by Anonymous Coward on Sunday July 19, 2009 @12:30PM (#28748615)

    It looks like the proof of concept only shows how this could lead to a stack overflow. There is no concept about how this could lead to code execution, which makes this just just another way to crash a browser.
    Crashing browsers is of course potentially a problem, but it quite boring while there are still so many ways to do real exploits.

  • fix: (Score:5, Funny)

    by Anonymous Coward on Sunday July 19, 2009 @12:31PM (#28748623)
    document.write = function(){ alert("This website was designed by a fucking idiot."); };
  • .. as the horrible language that is JavaScript is extended ever more to try and emulate real desktop applications (and more pervasive advertising).

    Mang, sometimes I wish I could still get by with a browser that doesn't support JS at all, but web devs insist on building websites that absolutely require JS. For example the free SMS service for my mobile phone network (Meteor) absolutely won't work with JS disabled.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      I don't know why you hate web applications so much but I agree that Javascript is a horrible language. The specification is gigantic and the language is overcomplicated.

      Lua [lua.org] makes a much better Javascript than Javascript. Small, lightweight and fast. Besides the syntax differences Lua is otherwise semantically very similar to Javascript except with a much better design... and Lua does it with a minuscule language syntax and VM.

      • The problem is that no one is going to switch to another language unless all the major browsers support it.

        People have tried to promote alternatives before (TCL and VBScript at least, probably a lot more I do not know about), but they never got anywhere.

    • Re:Expect to see much more of this in the future.. (Score:4, Insightful)

      by xlotlu ( 1395639 ) on Sunday July 19, 2009 @02:37PM (#28749409)

      Whoever modded the parent as troll is a moron. Offtopic maybe, but not troll. Go ahead and mod me down too.

      The parent is right. I've had my paranoid period and tried NoScript; the web was so damn broken, and clicking to allow JS over and over again turned so tiresome that I turned to everything whitelisted by default, and finally uninstalled NoScript after the AdBlock fiasco.

      About how bad of a language JavaScript is or isn't: I personally like it, though I'd prefer Lua, or say, Python; but JS is here to stay and it serves its purpose. Except that purpose isn't replacing HTML, or turning HTTP into something it was never meant to be. Back when I was coding JS, we were doing it to improve the user experience, not replace it altogether. Nowadays "web developers" use [insert random JS framework] for everything, but the problem is so, so many use it in braindead ways. You middle click on a thumbnail expecting to open the image in a new tab, but you just get the same page with a nice # added at the end. And then there's the idiots doing <a href="javascript:">, and the utter idiots with an attitude that do onclick="submit_something_via_post" and figure out they know better how the web is supposed to work... These are usually the same idiots that will do broken browser detection based on the User-Agent string, and usually fail miserably if your browser sends along "Gecko", but not "Firefox". Say, something like "Iceweasel". For a nice example of how far this stupidity goes, try browsing VIA's site.

      You want to use XHR when clicking on a link? Or submitting a form? That's all fine and dandy, but don't break the web. It's becoming more and more like flash, with the sole difference you can view-source.

      If you're building Google Docs or Meebo, all hail JavaScript. But for mostly everything else, lack of graceful degradation with JS disabled is pure idiocy. Not just because there's paranoid people browsing with JS disabled, but because there's blind people using the web, and people with antiquated handhelds, or simply stuck in a console trying to fix nvidia's latest fuck-up. Of course, it would take building the site / web app properly from the bottom up: HTML, server interaction, CSS, JavaScript. But the "developers" these day start with YUI or Dojo: some shiny animation is the end purpose in on itself, not an improvement to conveying information.

      By the way: did you try GMail with JS disabled? It works. It probably works in lynx too, since it works in elinks just fine. That's the way JS is supposed to be used.

      </rant>

  • Not just Firefox? (Score:5, Informative)

    by Norsefire ( 1494323 ) * on Sunday July 19, 2009 @12:42PM (#28748677) Journal
    The proof of concept has crashed every browser I've tried it on; Firefox (obviously) (and the 3.6 nightly), Epiphany, Chromium, Opera and Android Browser. So is Firefox the only browser that is exploitable during the crash or other browsers affected?

    • Re:Not just Firefox? (Score:4, Informative)

      by BZ ( 40346 ) on Sunday July 19, 2009 @01:13PM (#28748875)

      When I tried this, I see Firefox crashing with a null dereference. So not exploitable.

      Do you see something different?

      • No, that's what I see on every browser. I thought I must be missing something but it looks like this entire "exploit" is a non-event.

        • Re: (Score:3, Informative)

          by BZ ( 40346 )

          Well, the fact that SANS is blindly reposting known-unreliable things like milw0rm postins is something of an event, to me... Forgetting the fact that it tarnishes the reputations of whatever software they falsely accuse of being vulnerable, it leads to SANS being less reliable and less trusted. The whole crying wolf thing.

          But yeah, I agree that this "exploit" is nothing of the kind.

    • Re: (Score:3, Interesting)

      by Bacon Bits ( 926911 )

      It crashes FF 3.5.1 and Safari 4.0.2 for me, but not Chrome 2.0.172.37 or IE 8.

  • automate protection (Score:4, Interesting)

    by Anonymous Coward on Sunday July 19, 2009 @12:43PM (#28748693)

    These recurring requests to turn off something are getting annoying. Why not automate the process? Set up a page somewhere like
    www.mozilla.com/firefox/3.5.1/current-safety.txt

    which would list something like
    javascript: unsafe
    java: safe
    flash: safe

    Then by default your browser would fetch that file and automatically implement Mozilla's recommendation of the day.

  • No Javascript? No Firefox. (Score:3, Informative)

    by TheMCP ( 121589 ) on Sunday July 19, 2009 @12:51PM (#28748739) Homepage

    To say, for the contemporary web, "turn off javascript", is to say, "break everything". If I can't safely use the browser with Javascript, I can't safely use the browser.

    • I already replied in this thread, but wish I had mod points.. just the same, noscript is a pretty decent solution, as long as the sites you use detect/prevent user injection of js.

  • Firefox sucks (Score:5, Funny)

    by isa-kuruption ( 317695 ) <kuruption AT kuruption DOT net> on Sunday July 19, 2009 @01:18PM (#28748915) Homepage

    This is the reason why I avoid crappy software like Firefox and stick to MSIE! Firefox is riddled with bad, bloated code making it easily subjectable to these types of attacks. On top of that, the development model allows mistakes like this to get into the codebase without proper quality assurance.

    If I have to /sarcasm, I will kill you.

  • Firefox Vulnerability (Score:3, Funny)

    by DaveV1.0 ( 203135 ) on Sunday July 19, 2009 @01:21PM (#28748937) Journal

    But, but, but, that's unpossible!

  • This is a browser out of memory crash. There is no evidence that this is exploitable while all evidence points to it not being exploitable. Pretty much all browsers crash from this but that doesn't mean that it's a security issue.
  • Folks, Noscript will catch most Javascript exploits, but you should have a 'catch net'. AppArmor provides a 'sandbox' around any process you want. Firefox is a good example that I have written a how-to for creating an AppArmor Profile in Ubuntu 9.0.4 Read my blog here [dtschmitz.com] Be Safe. Dietrich T. Schmitz

  • Again, I think the NoScript UI should be part of the core Firefox product.

    Yes, there are many sites that require JavaScript. That's the point of NoScript--you can enable JavaScript for just the source domains you trust (e.g. Facebook), in a couple of clicks, and leave it disabled for all the other random sites you browse.

    And of course, the NoScript functionality would remain off by default, so naive users wouldn't be confused by it. Just like the functionality to not download images is off by default.

    • Re: (Score:3, Funny)

      by Fnord666 ( 889225 )

      you can enable JavaScript for just the source domains you trust (e.g. Facebook), ...

      You did not just say that. Tell me you did not just say that.

  • bug misreported, not exploitable, not a stack over (Score:3, Informative)

    by Mike Shaver ( 7985 ) on Sunday July 19, 2009 @05:30PM (#28750771) Homepage
    See http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ [mozilla.com] for more details, including specifics about how the bug affects different platforms and versions (worst case: unexploitable crash in OS X system libraries).

  • not exploitable (Score:5, Informative)

    by asa ( 33102 ) <asa@mozilla.com> on Sunday July 19, 2009 @06:47PM (#28751231) Homepage
    See what Mozilla has to say: http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ [mozilla.com] In the last few days, there have been several reports (including one via SANS) of a bug in Firefox related to handling of certain very long Unicode strings. While these strings can result in crashes of some versions of Firefox, the reports by press and various security agencies have incorrectly indicated that this is an exploitable bug. Our analysis indicates that it is not, and we have seen no example of exploitability. On Windows, Firefox 3.0.x is terminated due to an uncaught exception during an attempt to allocate a very large string buffer; this termination is safe and immediate, and does not permit the execution of attacker code. In Firefox 3.5.x on Windows, the allocations are more robustly checked and no crash will result. On the Macintosh in Firefox 3.0.x and 3.5.x, a crash occurs inside the ATSUI system library (part of OS X), due to what appears to be a failure to check allocation results. This issue is likely to affect any application using the recommended text-handling libraries on OS X. We have reported this issue to Apple, but in the event that they do not provide a fix we will look to implement mitigations in Mozilla code. We recommend that other developers who use these libraries consider a similar practice, and we have added mitigations in the past for similar bugs in these libraries. As a result of our analysis, we do not believe that this represents an exploitable vulnerability in Firefox. Further, we believe that the IBM report is in error, and that the severity rating in the National Vulnerability Database report is incorrect. We have contacted them and hope to resolve the inaccuracies shortly.

Slashdot Top Deals

Technology is dominated by those who manage what they do not understand.

Close