From the URL: "Late last week we become aware that it was possible to use the "-moz-binding" CSS attribute within Mozilla and Mozilla Firefox to execute arbitrary offsite JavaScript. As this attribute is designed to allow attaching an XBL transform and JavaScript to any node within the DOM, it is quite easy to use in a malicious fashion. We immediately altered our cleaner to strip this attribute from entries and comments, though also realized that wasn't even half the battle." https://bugzilla.mozilla.org/show_bug.cgi?id=324253 All versions affected.
*** This bug has been marked as a duplicate of 121363 ***
I don't see why this should be a dupe. This issue is neither listed in the other bug nor is Firefox 1.5.0.1 invulnerable.
Morning Jory, please advise:-)
1.0.8 and 1.7.13 delayed to sync with 1.5.0.2, ETA April 11th
This apparently is CVE-2006-0496, and not listed as fixed in 1.0.8 ?
I guess this one is either solved now or not practical, I suggest to close it. It's not as if we could do something about it.
Closing as per comment #6 and others.
It's neither impractical - just have javascript enabled, load some malicious website and wonder why your userdata from other sites gets used by others - nor fixed. Preinstalling the noscript
It's neither impractical - just have javascript enabled, load some malicious website and wonder why your userdata from other sites gets used by others - nor fixed. Preinstalling the noscript¹ plugin would be a possible measure (limiting the problem to the website the user trusts) until this problem gets fixed; And this seems to be something we can wait for a long while, when you look at the upstream tracker² bug. [1] https://addons.mozilla.org/firefox/722/ [2] https://bugzilla.mozilla.org/show_bug.cgi?id=301375
While integrating something like or bundling NoScript would be one of the best things that can happen to Firefox (Konqueror can do per-domain settings, Opera 9 can do it, heck, even IE can do it), it's not really helping the bug, since the regular user will not be able to make a meaningful decision whether to trust a site or not. So the question remains: Can _we_ fix something here?
Wolf, there are two points. It's a decission, if we ship a vulnerable Firefox by default, if we leave it to the user by disabling Javascript by default via the noscript extension, plus a relevant elog message to make the user aware of the problem - or if we mask it. I do favor the middle one, then the last, but the first is unreasonable in my eyes. Second, it's not the question, if we can fix it. That's upstream's job anyways. We track issues, until there's a fix or the relevant package is removed from the tree. And of course the user can make a meaningful decision, which sites he allows to use javascript: Either he's careful and enables it - as needed - only on his banking site and a limited number of sites he uses frequently, or he's not. But this isn't our problem anymore.
Carsten, I do agree with you ... but I don't know whether bundling NoScript on our side is the right thing to do. Maybe with a flag (like crypt on Thunderbird that integrates Enigmail, IIRC) that defaults to enabled. Otherwise the user ends up with an extension he can't disable himself (because it's not in his profile). If this does not raise concerns for any of you, then by all means, let's do it. I just hope Mozilla integrates something like that. The sooner the better ...
The thing is, with a security-aware upstream with complex codebase like Mozilla, there is little to do but to wait for a fixed release. If they can't design a patch for this in months, we probably can't do better. That's why I'd close all Mozilla individual bugs and open bugs about it only when that's something we can workaround in Gentoo or when a new version is released by the MozFo...
(In reply to comment #12) > That's why I'd close all Mozilla individual bugs and open bugs about it only > when that's something we can workaround in Gentoo or when a new version is > released by the MozFo... Then let's workaround it at least a bit and slipstream NoScript by default. IMHO it's our job to help users that are less aware of sec issues than we are. If we can do some education and give a little starter help, then at least we do something to make more people aware. If they later on decide to enable JavaScript globally, it can't be helped, abviously. Nevertheless it's worth the effort, I think. Just print a *big* ewarning (ah, I really hope we'll have ELOG=save and an accompanying directory by default in the future).
(In reply to comment #11) > Carsten, I do agree with you ... but I don't know whether bundling NoScript on > our side is the right thing to do. The alternatives are leaving our userbase with a browser, which allows site owners to spy out user data or to mask a widely used application... > Maybe with a flag (like crypt on Thunderbird > that integrates Enigmail, IIRC) that defaults to enabled. The whole point of my idea to install this extension is to force it. > Otherwise the user > ends up with an extension he can't disable himself (because it's not in his > profile). Two mouseclicks and all scripts pass through, if the user chooses to. (In reply to comment #12) > The thing is, with a security-aware upstream with complex codebase like > Mozilla, there is little to do but to wait for a fixed release. If they can't > design a patch for this in months, we probably can't do better. > > That's why I'd close all Mozilla individual bugs and open bugs about it only > when that's something we can workaround in Gentoo or when a new version is > released by the MozFo... I don't agree with this, Thierry. It doesn't cost us anything to keep tracking such bugs until the issues are really fixed. At least, when it's not a minor issue. I'd favor installing the noscript extension, since it closes the hole to the degree and as long as the user wishes as well as issueing a "preliminary" GLSA.
Agreed. It's probably interesting to get the Mozilla maintainers advice on this. Two options : keeping the bug opened until the MozFo closes the hole, or proactively fix it by bundling the NoScript extension.
My $.02: Something like NoScript should be bundled with any browser. It does not close any holes, but instead minimizes the number of holes opened, what seems like good policy and a safe approach to me.
Any news on this one?
No answer from the mozilla herd so far.
firefox-2.0 ships with the ability to disable javascript globably with the restrcit-javascript useflag.
Firefox-2.0 is not known to be vulnerable according to SecurityFocus. I'm closing. Feel free to reopen if you disagree.
