Firefox Update Fixed A Bunch Of Things
Whelp, we sorta missed this one, because, well, it wasn’t announced to us… but it turns out that Firefox had a lot of issues that were kept tight lipped until they could release a patch. Probably the most interesting to me was CVE-2006-6503 which still has the details hidden from view on bugzilla and the name of the person who reported it is masked as “moz_bug_r_a4″.
From what I can gather from the various sites apparently if you have an image inside of an iframe you can change the img.src attribute to be a javascript: directive thereby bypassing their internal XSS filters. Interesting. Of course I always try to keep an out of date version of a browser around for a few days, so if anyone can think of how this exploit worked, I’d be curious to know how, just from a research perspective.
I’ve got to tell you, I’m not thrilled by their non full-disclosure policy. I thought open source was supposed to be just that. One of the major advantages of an open sourced browser is that I know everything that’s going on with it. Telling me to “turn of JavaScript” is not enough information for me personally. So there went one of the major advantages for me. I’d be curious to hear other people’s thoughts.
December 21st, 2006 at 11:09 am
“moz_bug_r_a4″ is not an attempt to hide anything (on Mozilla’s part), it’s the only handle given for him or her: https://bugzilla.mozilla.org/buglist.cgi?emailreporter1=1&emailtype1=substring&email1=moz_bug_r_a4
The trick used is non-obvious and wouldn’t apply to any other browser. What purpose would it serve to publish the exploit details immediately without giving people a chance to get the fix? There is nothing you as a user or web app developer can do to prevent this exploit other than turn off JavaScript.
The source -is- open; the checkins that went into 1.5.0.9 are found at http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_0_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-01&maxdate=2006-12-09&cvsroot=%2Fcvsroot
and that link and more can be found off our tinderbox pages http://tinderbox.mozilla.org/Mozilla1.8.0/ (and /Mozilla1.8/ for the 2.0.0.x releases).
The checkin comment should have included the bug number, this one didn’t for some reason (you can see all the rest do). It’s the check-in by “jst” on 12-01, the one that isn’t for bug 357651.
December 21st, 2006 at 2:42 pm
dveditz, thanks for writing. I have a few comments (and glad to know that isn’t a cover-up, if that really is the person’s handle):
1) “The trick used is non-obvious and wouldn’t apply to any other browser.” I hope so, but did you or someone else try every single other browser? Netscape is always a version or so behind, so are they vulnerable in that they use the Gecko rendering engine? This isn’t as cut and dry an issue to security researchers.
2) “What purpose would it serve to publish the exploit details immediately without giving people a chance to get the fix?” For research - so that we can know what the bug is, know what to look for in the future, and perhaps fix it ourselves in our own browsers. Believe it or not some people tweak/recompile their own browsers.
3) “There is nothing you as a user or web app developer can do to prevent this exploit other than turn off JavaScript.” Be very careful here, there is one thing all people can do - switch to another browser.
I’d much rather give a wide berth to the hocus pocus and have at least one browser company be straight with consumers. I understand the desire to protect people, but keeping it out of public view doesn’t protect them, it keeps the level of exposure higher because they don’t know how to protect themselves (whether that be by using another browser or by turning off JavaScript or what have you). Without knowing the details there is no way for them to gauge how bad something is, and therefor they won’t do even the simple mitigation of turning off JS.
Let’s put it this way, if I don’t know about it there is no way my mom knows about it. And if she doesn’t know about it, she’s not safe using your browser and cannot make an informed decision about what browser to use. Tell me how that is any different than Internet Explorer. What’s the benefit for a consumer? Even I tell people that they aren’t safe on my site while I have an XSS hole. I don’t hide that fact - I just fix it as quickly as possible. People need to be warned when they are putting their financial security at risk by using your software. But I also happen to be one of the biggest consumer advocates you’ll ever meet, so you can feel free to ignore me.
Anyway, I’ll take a look at the code, now that I know where to look. Thanks for the links! I owe you a beer.
December 21st, 2006 at 8:49 pm
1) it will affect all Mozilla-derived products, no need to test those
2) Delaying release of details for a couple weeks doesn’t hurt research in the end, and does give time for users to upgrade and for downstream vendors to release updates before the script kiddies go wild adapting the testcase code.
3) sounds like you’re arguing for full-disclosure the instant Mozilla learns of a flaw? How does that not put people more at risk?
In the end everything in Mozilla is public: the code, the check-in history, and all the bugs (eventually). People certainly have the data to judge us, and if we’ve mishandled things it can be pointed out so we can improve in the future.
December 22nd, 2006 at 9:36 am
It’s snobbery to think you’re protecting the little guy by being a fascist. I would hope that in future societies, this is instead seen as criminal.
full-disclosure and exploit are not the same thing. PoC and exploit can be the same thing, but they don’t have to be in all cases. notice how RSnake never used the word “exploit”, but dveditz was quick to play that card.
one can argue that it’s easy to reverse-engineer a patch into an exploit. I instead argue that it’s impossible to write a third-party patch without complex reverse-engineering and guesswork. this does hurt research, and it doesn’t seem to benefit the users.
next on the agenda of “responsible disclosure” is to share the information with only a “select few”. hell, for all I know - mozilla is already doing this. in this scenario, complete disclosure is shared with those who require the information for just-in-time patching systems such as network and host IPS. which, of course - includes monetary contributors to the project such as Tippingpoint or Symantec, but discounts snort-inline and open-source vulnerability scanners (which don’t exist at this time). or distribution channels and vendors. or the project owner’s mother. does anyone besides myself see this as slippery-slope?
also - i’ve seen this “moz_bug_r_a4″ myself when looking at firefox’s bugzilla and also assumed it was some sort of attempt to hide the person or organization behind a security-related bug/advisory. thank you for clearing this up for us.
RSnake - kudos to you for sticking up for consumers’ rights.
December 27th, 2006 at 1:01 am
right, i dont see anything wrong with not sounding the trumpets as soon as a bug is found that is easy to exploit and can run wild on your browser. its complete nonsense, if you really wanted to know about the bug you could have payed more attention on some forums.. i’ve noticed talk about this for a while now, and dont think you’re going to look like the folk hero just for ’sticking it to the man’ because its people like you that make it easy for the script kiddies and hard for the people that do the work (which will most likely never be you)
December 28th, 2006 at 7:56 am
tyr: in response to your post
“…hard for people that do the work”
i’m not sure if you mean the programmers that have to fix the bug or if you refer to the administrators that have to respond, patch, and/or rollout upgrades. i’ve been on all sides of this issue, so allow me to elaborate.
first of all, it was the programmers (probably same ones) that wrote the bug in the first place. it’s their responsibility to clean it up, and to do so very quickly and thoroughly. the worst part about programmers addressing a fix is that 20 to 50 percent of the time they introduce a new bug.
the problem of bad programmers who make huge/critical mistakes can only be rectified by firing them or “forced lateral moves”. this can get expensive, especially since the person you want to hire to replace them has to be better (and usually has higher salary requirements). using “more secure” programming languages or frameworks doesn’t seem to make a dent, but other methods (whitebox static source code analysis combined with strong blackbox vulnerability assessment - best done before the product goes into usability testing) often work really well.
secondly, if you refer to administrators: this is also a part of their job. note that programmers (not always open-source programmers, but they usually get some sort of benefits/donations) and administrators get paid seriously rediculous amounts of money compared to the common person.
administrators need full-disclosure because they need to gauge their response to an issue by priority/importance.. there may be more than one way to patch/respond to the issue, and when and where and how to patch/respond come into play. the decision-making process can get complex.
an administrator may find him/herself asking questions like, “do I write an ACL or firewall rule to block this malicious traffic?”, “do I push that rule down to software firewalls?”, “will my IPS provide JIT patching for this bug and is it good enough?”, “do the AV and HIPS solutions in place provide prevention against this threat?”. “does my patch management solution work to my needs for this bug and getting out a real fix?”, “is my incident response good enough to respond to this issue if an infection occurs?”, “is my forensics capabilities up to par to investigate possible intrusions?”… you see where this is going by now?
if an administrator gets an email from a vendor indicating a huge security hole - followed by a brief description I
of the problem and “to turn off a major feature in the product until such time as we come up with a real fix”… he/she would be more likely to uninstall said app and use a competitor’s product than face such a “great unknown” risk. if he/she doesn’t hear about the huge security hole that puts the infrastructure “fully” at risk.
“…make it easy for the script kiddies”. one response to this: PROVE IT. show me statistics correlating full-disclosure (sans exploit) to script-kiddie abuse. I want detailed metrics. providing running malware is good, but how do I know that this malware wasn’t already fully developed before the full-disclosure took place? maybe these script-kiddies knew all along, discovered it on their own two years before the vendor found it themselves, and didn’t tell abybody.
“…look like the folk hero just for sticking it to the man”
most full-disclosure still involves people hiding behind anonymity (i.e. fake names, remailers, etc). most vulnerability hunters never get paid (or expect to) or reimbursed for their work.
it’s hard to get famous when you are hiding your identity. these is nothing more true to the description of a folk hero… if you are aware of superman/spiderman, you might understand the logic here.
moz_bug_r_a4 and RSnake… case in point. lack of google adsense or other ads here… second case in point.
I have several thousand other arguments and points to make about vulnerability disclosure… but they’ll have to wait until the world is ready for them. it’s a general lack of understanding with regards to people like “tyr the mighty” that make me think we have a long way to go before understanding this at a base level.