289083 - |new Script()| causes arbitrary code execution

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[moz_bug_r_a4]

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:

Comment 1

[moz_bug_r_a4]

Attachment: testcase 1

this requires user's click action.

Comment 2

[moz_bug_r_a4]

Attachment: testcase 2

this does not need user interaction.

for Firefox/1.0.2, Firefox/1.0.3, Mozilla 1.7.6, Mozilla 1.7.7

Comment 3

[moz_bug_r_a4]

Attachment: testcase 3

this does not need user interaction.

for Firefox 1.0+, Mozilla 1.8b

Comment 4

[Johnny Stenback (:jst)]

Attachment: Make sure we get the right principals when dealing with JS created Scripts.

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).

Comment 5

[Johnny Stenback (:jst)]

Fix landed for 1.0.3.

Comment 6

[Brendan Eich [:brendan]]

Wanted in 1.7 branch and trunk, of course.

/be

Comment 7

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

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.

Comment 8

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

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

Comment 9

[Johnny Stenback (:jst)]

Attachment: Same fix including the comment changes that landed on the aviary branch.

Comment 10

[Asa Dotzler [:asa]]

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?

Comment 11

[Asa Dotzler [:asa]]

dan says bug 281988 superceedes this. unblocking 1.8b2.

Comment 12

[Juha-Matti Laurio]

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 .

Comment 13

[Juha-Matti Laurio]

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

Comment 14

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

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