Slashdot Mirror


Hackers claim zero-day flaw in Firefox

An anonymous reader writes "The open-source Firefox Web browser is critically flawed in the way it handles JavaScript, two hackers said Saturday afternoon. An attacker could commandeer a computer running the browser simply by crafting a Web page that contains some malicious JavaScript code, Mischa Spiegelmock and Andrew Wbeelsoi said in a presentation at the ToorCon hacker conference here."

24 of 398 comments (clear)

  1. Impossible to patch? by Anonymous Coward · · Score: 3, Informative

    What about NoScript? http://www.noscript.net/whats

    1. Re:Impossible to patch? by LaughingCoder · · Score: 4, Informative
      surf there with a locked down browser.
      Or better yet, use a wide open browser inside a virtual machine.
      --
      The more you regulate a company, the worse its products become.
    2. Re:Impossible to patch? by Anonymous Coward · · Score: 1, Informative
      Admittedly, this strategy will fall down if a mainstream site I visit with my fully enabled browser is compromised by a third party.

      You mean like what happened with the recent CPanel exploits? It's dumb luck that that wasn't used to spread a Firefox exploit as well...

    3. Re:Impossible to patch? by FLEB · · Score: 2, Informative

      Use the "insecure" one for banking, etc.

      Typo-- use the "secure" one for banking, etc.

      --
      Information wants to be free.
      Entertainment wants to be paid.
      You just want to be cheap.
  2. Good policies will often save you. by failure-man · · Score: 3, Informative

    Noscript is your friend. Been using it for a year or so now.
     
    Yes, whitelisting sites is a pain, but Javascript is a remnant of a more innocent time and should probably be phased out anyway.

    1. Re:Good policies will often save you. by Vo0k · · Score: 5, Informative

      Sandboxing the whole thing will help against system takeovers, but not against frauds within the browser - cross site scripting etc.

      Running a sandboxed version of a scripting language within a browser should be pretty harmless if the language was available only in the sandbox and couldn't touch anything outside. Creating separate sandboxes for each website would prevent cross site scripting too.

      The problem is it's impossible with Firefox. It's a very old design decision that is so deep all over the place that nothing short of redesigning and rewriting everything from scratch could help.

      Essentially, Firefox is written in javascript.

      There are underlying frameworks written in C++ and others, the renderer engine etc etc. But the glue that binds all these functions together is Javascript on steroids. XUL files-databases that define the looks of the UI, XUL renderer, which displays them, and thousands of lines of javascript bound to every single gadget, button, field, box, dialog. This javascript performs all the basic processing and the whole high-level work of the browser program. And it calls system/framework functions to perform the low-level work - which is strictly forbidden for a sandboxed language.

      Developers of Mozilla try to prevent access to all this low-level heavyweight stuff from javascript originating from webpages while allowing it from the system files. Sandbox javascript from one source, run javascript from the other source at full privledges all the time. Can you smell how fragile this is? I'm afraid these exploits will keep popping up. There's no natural barrier of "contained sandbox environment + scripting language" vs "low-level system layer", with no trace of bindings to the system layer within the sandbox, no hook, no crack to exploit by interfacing with the outside. There's an artificial wall which limits "javascript from webpages" and allows "extended javascript from interface", where both sides are essentially the same thing.

      This is the old firewalling problem - policy of "deny all, allow essential" vs "allow all, block dangerous". Except currently there is no easy way to switch from one to the other.

      --
      Anagram("United States of America") == "Dine out, taste a Mac, fries"
  3. Re:Intersting Spin by Smidge204 · · Score: 1, Informative

    Difference is either a) The exploit is announced by a credible soruce, or even the software vendor (Microsoft in those cases) or b) A Proof of Concept demonstration of the falw is provided.

    Neither of which apply to this situation. An announcement from a crerdible source or a demonstration would clear things right up. Even if you consider whitedust.net to be a good source, the flaw was not found by them and they only reference a ZDNet article which contains slightly more information but not enough to really confirm anything. The people who found the exploit are deliberately keeping it secret and therefore will not produce a PoC.
    =Smidge=

  4. Re:Intersting Spin by RonnyJ · · Score: 2, Informative
    You sure neither of those apply? From the article:

    The JavaScript issue appears to be a real vulnerability, Window Snyder, Mozilla's security chief, said after watching a video of the presentation Saturday night. "What they are describing might be a variation on an old attack," she said. "We're going to do some investigating."

    Snyder said she isn't happy with the disclosure and release of an exploit during the presentation. "It looks like they had enough information in their slide for an attacker to reproduce it," she said. "I think it is unfortunate because it puts users at risk, but that seems to be their goal."

  5. IRC by Anonymous Coward · · Score: 5, Informative

    have you guys heard about the supposed vuln in firefox disclosed at toorcon today?
    <Ryan> "Firefox re-entrant threading"?
    <reed> http://www.toorcon.org/2006/conference.html?id=13
    <Jesse_> yeah, that one
    <reed> Jesse_: Did you go to that particular one?
    <Jesse_> yes
    <Jesse_> i also went up on stage to "debate" "disclosure" with them
    <Jesse_> when i said "debate" "disclosure", i didn't mean the usual "how much time should security researchers give vendors to write and deploy patches before making the holes or exploits public" debate
    <Jesse_> these guys were *against* disclosure
    <Jesse_> preferring to keep the status quo of lots of vulnerabilities, large botnets (so they can be anonymous), etc. or maybe they were joking, it was hard to tell.
    <Jesse_> they claim they can make $10,000 or $20,000 selling a vuln in firefox
    <Jesse_> compared to $500 telling us about it
    <Jesse_> selling to other blackhats, anonymously, using onion networks, of course
    <dveditz> TippingPoint and iDEFENSE will pay up to $10K for IE and probably firefox vulns

    . . .

    <jX> http://news.com.com/Hackers+claim+zero-day+flaw+in +Firefox/2100-1002_3-6121608.html
    <jX> "...what we're doing is really for the greater good of the Internet, we're setting up communication networks for black hats," How exactly is that for the greater GOOD?
    <dveditz> the black hats crusade for our freedom (and credit cards) against the evil fascist empire
    <dveditz> they *earn* everything they steal by doing all the good they do keeping "the man" from owning the internet

    . . .

    <Jesse_> http://news.com.com/Hackers+claim+zero-day+flaw+in +Firefox/2100-1002_3-6121608.html quotes me out of context in a way that makes it look like i'm trying to bribe them with $500 bug bounties :(
    <zach> Jesse_: they dragged you up on stage during their talk?
    <jX> Jesse_: Yeah, doesn't reallyt make anyone look good, that article..
    <Jesse_> "I do hope you guys change your minds and decide to report the holes to us and take away $500 per vulnerability instead of using them for botnets" is pretty close to the BEGINNING of a sentence i said
    <Jesse_> the REST of the sentence was " or selling them to other blackhats for ten thousand dollars"
    <Jesse_> with the whole sentence, it's clear that i'm hoping they'll change for ethical reasons, and that i'm not trying to bribe them
    <jX> Jesse_: Yeah, but quoting you out of context makes for better copy.
    <zach> Jesse_: did they actually drag you on stage during their talk as the article suggusts?
    <Jesse_> zach: they left a lot of time after their slides, and asked me to come up
    <Jesse_> zach: they told me before the talk that they might ask me to come up
    <Jesse_> dveditz: yeah, about 20 minutes before

  6. Re:Proof? by tomhudson · · Score: 4, Informative

    Yes they did have a live exploit.

    No, they didn't have a live exploit. The original article is here http://news.zdnet.com/2100-1009_22-6121608.html, not the site linked to by slashdot.

    All they had was a video ... no code to display.

    So, maybe they do, maybe they don't ... but you can't tell just from a video.

    The JavaScript issue appears to be a real vulnerability, Window Snyder, Mozilla's security chief, said after watching a video of the presentation Saturday night.

    Also, what sort of drugs do you have to be on to name your kid "Window"? Brings to mind Frank Zappa naming his kid "Moon Unit".

  7. Re:How Java Script Should Be Handled by TwilightSentry · · Score: 2, Informative

    It is, in just about every browser except IE (Well, okay, it seems to be there in IE7, but time will tell if it's garbage). The problem is that no code is perfect; a seemingly benign function can have, for example, a bufferr overflow that allows some JS to insert code into the browser and have it run...

    --
    How to enable garbage collection on a system without protected memory: #define malloc() ((void *) rand())
  8. Re:Selling bugs to the highest bidder by jesser · · Score: 3, Informative

    Yeah, right. What they are really saying is, why give away a bug for $500 when we can sell it for much more on the black market?

    If CNET hadn't cut off my quote mid-sentence, it would have been clear that that was what (jokingly) saying too. I was not trying to bribe them. I was trying to say that I hoped they would change their minds and report the holes to Mozilla despite the fact that they (claimed they) could make much more money exploiting the holes or selling information about the vulnerabilities on the black market.

    --
    The shareholder is always right.
  9. Re:Recent fixes by jesser · · Score: 4, Informative

    No. Those three bugs were holes I found before ToorCon.

    --
    The shareholder is always right.
  10. The real storry by augustz · · Score: 4, Informative

    To be clear:

    Firefox had a build switch that allowed folks to build it without branding (and do whatever they wanted to it) or build it with branding (and follow Mozilla's rules to create a consistent user experience).

    Debain dev's took that build switch and broke it, so that everyone wanting to modify or adjust the debian firefox packages would have to go through and hand edit out firefox if they wanted to remove branding. They then packaged this broken thing up, and still called it firefox.

    Mozilla said that was bogus, and they were right. Having that build switch makes it easier for folks to make changes to the package without worrying about branding. Redhat and others do exactly this with artwork/branding packages. We are ALL better off if such easy build time switches are available.

    I've been around a while, but the debian developers are way out of line here.... You can't create some crazy messed up debian distro and call it debian, you can't create a crazy redhat distro and call it redhat, why is firefox getting all this heat? The amount of fuss they are creating is bogus and dissapointing. I read through the snide commentary and it really is depressing. Even Mozilla Foundation suggests that a non-branded version of firefox would work better for them.

    1. Re:The real storry by thebluesgnr · · Score: 4, Informative

      That's not the real story. In fact it's a bogus story that omits a very important detail, which is that Debian had permission from Mozilla (Gervase Markham) to use the Firefox branding the way they were using it. See the bug report for the real story: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3 54622

  11. No-Script by Ice+Wewe · · Score: 5, Informative
    ...An attacker could commandeer a computer running the browser simply by crafting a Web page that contains some malicious JavaScript code...

    Which is why it's smart to run NoScript. A Firefox extention that blocks the execution of any scripts on a webpage without user concent. So, if you're tired of Javascript taking over your Firefox, get NoScript.

    https://addons.mozilla.org/firefox/722/

  12. Re:Back on topic... by symbolic · · Score: 4, Informative

    This exploit (or one similar) was mentioned in an episode of Security Now (about 3 weeks ago, I think). A potential solution was install a plugin called noscript, which allows the user to enable javascript on a per-site basis. I've used it since I heard about it, and I believe it can play a major role in preventing the execution of any rogue javascript.

  13. Re:Slightly offtopic... by TheLink · · Score: 2, Informative

    Run it using another user. Works under windows too, even with IE.

    Just most Windows/Linux users don't know that, or do that.

    You need to set up permissions so that your downloads can be accessible (and deletable) from your main account, but that's not too difficult under Windows, and fiddling with some ACLs on Linux. In fact I found it harder to do the permissions thing on Linux.

    The other option is to run in in a virtual machine. The other benefit is firefox/mozilla can't use more RAM than the VM limit ;). I've had Mozilla use 1GB of mem before.

    --
  14. Re:Terrorist Actions?? At least Criminal by mrogers · · Score: 2, Informative
    You know, there are folks out there who would call what these hackers are doing an act of terrorism.

    In the UK, interfering with any electronic system for political purposes is defined as terrorism. The same definition of terrorism is used in a more recent law that criminalises speech that glorifies terrorism.

    Of course, that says more about the abuse of the word "terrorism" than it does about the morality of withholding exploits.

  15. Too bad JavaScript is THE WORST language by SimHacker · · Score: 2, Informative

    That's too bad about FireFox being essentially written in JavaScript. SpiderMonkey, the JavaScript interpreter in Firefox, is BY FAR the worst programming language (in terms of speed and memory use) of them all, according to the Computer Language Shoot Out.

    When you compare all the languages on CPU time, SpiderMonkey JavaScript is twice as slow as the second worst, Ruby.

    When you compare all the languages on memory usage, SpiderMonkey is 1.7 times as bloated as the second worst, Smalltalk Visual Works.

    When you compare all the languages on CPU time AND memory usage, SpiderMonkey is 2.1 times as bad as the second worst, Smalltalk GST.

    Firefox would be much better off using Lua, which is much easier to integrate with C code than SpiderMonkey's nightmare sausage factory, much faster, much smaller, and a vastly better language design. The fact is, that good language design has a huge effect on speed and memory usage -- you can't just stick your head in the sand and pretend good language design isn't important, like the PHP and JavaScript designers originally did and still do. Bad design paints your bad implementation into a bad corner, and there it stays.

    Here's how Lua and SpiderMonkey JavaScript stack up against each other. Lua TOTALLY smokes JavaScript, in every category, by a long shot. It's not even funny -- it's tragic. Face it: JavaScript is not only a horribly designed language, but SpiderMonkey is also a horrible implementation of that horribly designed language. So it's not surprise that SpiderMonkey has always had gaping security holes, to complement its horribly slow speed and extremely huge size.

    Lua x times better than SpiderMonkey JavaScript
    binary-trees: 2.9 x faster, 6.6 x smaller
    cheap-concurrency: No SpiderMonkey
    fannkuch: 3.8 x faster, 1.2 x smaller
    fasta: 8.2 x faster, 13.9 x smaller
    k-nucleotide: 3.7 x faster, 10.0 x smaller
    n-body: 6.3 x faster, 77 x smaller
    nsieve: 7.8 x faster, 2.0 x smaller
    nsieve-bits: 2.3 x faster, 29 x smaller
    partial-sums: 7.0 x faster, 80 x smaller
    recursive: 2.9 x faster, n/a3
    regex-dna: 1.9 x faster, 5.3 x smaller
    reverse-complement: 8.0 x faster, 5.8 x smaller
    spectral-norm: 6.2 x faster, 71 x smaller
    startup: 1.2 x slower, 1.1 x smaller
    sum-file 5.3 x faster, 21 x smaller

    -Don

    --
    Take a look and feel free: http://www.PieMenu.com
  16. Re:Slightly offtopic... by Emetophobe · · Score: 2, Informative

    A simple fix would be to use the NoScript extension and just allow javascript on the few trusted sites you visit that require javascript. You can also block java, flash and other plugins with NoScript.

  17. Re:you are deluded by causality · · Score: 2, Informative
    Wouldnt having at least your web browser running under a non-priveleged account other than root protect you from buffer overflows being able to damage the system?

    A buffer overflow exploit can allow attackers to gain the same privileges as the user who is running the browser. A regular user account is sufficient to participate in a botnet (including DDoS attacks), become a spam zombie, or become some script kiddie's "warez" fileshare. Consider also that most of your data would be stored in your user's home directory, and you now have a potential identity theft (depending on your habits and whether you use strong encryption). This is not as bad as, say, an Internet Explorer exploit that gives complete "Administrator" access to to the entire machine and all accounts on it, but (as you mentioned) it could be followed up by privilege escalation attacks which could then lead to root access.

    To dismiss regular user accounts as unworthy of protection is a big mistake. When discussing remote exploits (as opposed to local security), the user system is more like a form of damage control.
    --
    It is a miracle that curiosity survives formal education. - Einstein
  18. Re:"sandbox" is a pathetic rationalization here by Anonymous Coward · · Score: 1, Informative
    Still pretty damn good. Because while hacking the browser may get you limited access to my Linux box, it gives me UNLIMITEd access to your Windows box.
    You keep spouting this nonsense, despite many people already correcting you. The browser in Windows can be run from a sandbox every bit as well as it can in Linux. And, by the way, I run Linux, not Windows.

    Actually it was a 'I'm sandboxed' rationale if you want to be that anal and browser security can only take into consideration threats on the client side; sandboxing your apps is step one of many. But in this case since it can comprimise a Windows system entirely and give ROOT access, I'd say sandboxing your app would have prevented this. Remember, keep the arguiment in context to the original discussion and you'll always sound like you know something about what you're talking about.
    You are an amazingly dishonest person. You stated, in no uncertain terms, that a browser flaw was only an issue in Windows, not Linux. "No problem here. Hijack my browser all you want, you're sandboxed." You now admit that is bogus, but you try to weasle your way out by falsely accusing me of taking the argument out of context. There is a problem when running a hijacked browser on Linux, as several people have clearly demonstrated to you. You know, you could just admit it when you're wrong and move along, instead of acting like a child.
  19. False by augustz · · Score: 2, Informative
    I've read the entire bug. I've read the email thread. This is important to have the full context of this this on the record. The claim you state as a fact, that "Debian had permission from Mozilla to use the Firefox branding the way they were using it" is disputed. In fact, a careful read of the bug and associated email threads will show that it is a very weak claim.

    Here is a quote from an email from Mozilla that captures this nicely:


    At no time was any irrevocable and/or condition-free usage of the
    trademark granted. Nor do I see anything about just using the name
    and not the artwork ... One of the last things I see in the June
    thread was this quote:

    "So I believe
    my best option is to ignore the trademark policy altogether and have
    the Mozilla Foundation tell us when they want us to stop using their
    marks. Now I originally said we shouldn't do this, but it does have
    certain advantages. First of all, I think we can ignore the trademark
    policy because it is only a policy, is not distributed with the
    software (although having said that, that might change) and it is my
    understanding that in most jurisdictions the trademark holder has to
    police use of their trademark anyway."

    In that light, you should consider this, as I previously said, notice
    that your usage of the trademark is not permitted in this way, and we
    are expecting a resolution. If your choice is to cease usage of the
    trademark rather than bend the DFSG a little, that is your decision
    to make.


    A couple things are important here. First, does that look like things were agreed to on a license grant? I read this as debian deciding to ignore the policy. Second, does debian have the right to sublicense their supposed grant to avoid the artwork and change the packages to other groups who want to use firefox? I doubt it, even under the debian interpretation of a grant. So you've broken the DFSG with the community who would use debian, and is going to be stuck tearing out references to firefox by hand now if they want to create works based on debian.

    The choices here seem pretty clear. Fight a legal fight (that despite your "fact" you are likely to loose becuase you expressely state you are going to ignore the policy), or make a small and simple change that will avoid the whole issue together.

    This is a losing debate I think for debian, because regardless of what legal technicalities you try and hang your hat on, you are going to find little support for your actions, because almost EVERY open source project actively discourages your type of activity, which is striping visual identity, changing packages, but keeping a trademarked name. I suspect debian would take the SAME position with others creating versions of debian and calling them debian.

    Why then fight so hard to do something that you would make a stink about elsewhere, even if you think you can get away with it, especially given how very weak the case is to someone who has actually read the entire bug and entire email thread.

    It seems time could be better spent on other things.