User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 Even though a |Script Object| is created by a web page, when it is called from chrome JS, it is executed with chrome privilege. If a web page redefines |localName getter| of a DOM node, such as following. document.body.__defineGetter__("localName", function() { return { toLowerCase : new Script("alert(Components.stack);") }; }); Then, if there is a code such as the following code in chrome JS, "alert(Components.stack);" will be executed with chrome privilege. local_name = event.target.localName.toLowerCase(); In addition, |typeof new Script()| is "function" in Firefox1.0.2 and Mozilla1.7.6 (it is "object" in latest-trunk), thus, it is easier to write a exploit code, such as following. document.body.__defineGetter__("localName", new Script("alert(Components.stack);")); And an attacker can exploit *without* user interaction, by using DOMLinkAdded Event. I have confirmed that the following testcases work in: [Firefox] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050404 Firefox/1.0.3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+ [Mozilla Suite] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050404 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404 Reproducible: Always Steps to Reproduce:

this requires user's click action.

this does not need user interaction. for Firefox/1.0.2, Firefox/1.0.3, Mozilla 1.7.6, Mozilla 1.7.7

this does not need user interaction. for Firefox 1.0+, Mozilla 1.8b

This fixes this by ensuring that we don't give elevated priveleges to content code in a Script when called from chrome. r+sr=brendan (in person).

Fix landed for 1.0.3.

Wanted in 1.7 branch and trunk, of course. /be

Comment on attachment 179827 [details] [diff] [review] Make sure we get the right principals when dealing with JS created Scripts. r=dveditz fwiw, though fix the missing apostrophes in the comment block.

Original testcases fixed by this patch, but see bug 289074 comment 13 and the testcase in attachment 179875 [details]

This still needs to land on the trunk? a=asa for trunk landing if it's simply migrating the same patch to the trunk. Is there anything else that's needed here?

dan says bug 281988 superceedes this. unblocking 1.8b2.

This was assigned as SA14938's vulnerability #8; http://secunia.com/advisories/14938/ and as http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1160 .

Additionally, this is one of April's (i.e. 1.0.3) MFSA's classified as 'Critical': http://www.mozilla.org/security/announce/mfsa2005-41.html

This has been landed on the trunk as part of bug 281988. Although parts of 281988 have been backed out, this much remains.