|new Script()| causes arbitrary code execution

RESOLVED FIXED

Status

()

Core
Security
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: moz_bug_r_a4, Assigned: dveditz)

Tracking

({fixed-aviary1.0.3, fixed1.7.7})

Trunk
x86
Windows XP
fixed-aviary1.0.3, fixed1.7.7
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.7 +
blocking-aviary1.0.3 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix])

Attachments

(5 attachments)

(Reporter)

Description

13 years ago
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:
(Reporter)

Comment 1

13 years ago
Created attachment 179682 [details]
testcase 1

this requires user's click action.
(Reporter)

Comment 2

13 years ago
Created attachment 179683 [details]
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
(Reporter)

Comment 3

13 years ago
Created attachment 179684 [details]
testcase 3

this does not need user interaction.

for Firefox 1.0+, Mozilla 1.8b

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 256195

Updated

13 years ago
Flags: blocking1.7.7?
Flags: blocking-aviary1.0.3?

Updated

13 years ago
Blocks: 289187

Updated

13 years ago
Blocks: 289074
Created attachment 179827 [details] [diff] [review]
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).
Attachment #179827 - Flags: superreview+
Attachment #179827 - Flags: review+
Fix landed for 1.0.3.
Keywords: fixed-aviary1.0.3

Updated

13 years ago
Flags: blocking1.7.7?
Flags: blocking1.7.7+
Flags: blocking-aviary1.0.3?
Flags: blocking-aviary1.0.3+
Wanted in 1.7 branch and trunk, of course.

/be
Flags: blocking1.8b2+
Attachment #179827 - Flags: approval1.7.7+
Attachment #179827 - Flags: approval-aviary1.0.3+
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]
Created attachment 179895 [details] [diff] [review]
Same fix including the comment changes that landed on the aviary branch.
Depends on: 281988
Whiteboard: [sg:fix] hold private until April 25,2005

Comment 10

13 years ago
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?
Group: security
Keywords: fixed1.7.7
Whiteboard: [sg:fix] hold private until April 25,2005 → [sg:fix]

Comment 11

12 years ago
dan says bug 281988 superceedes this. unblocking 1.8b2.
Flags: blocking1.8b2+

Comment 12

12 years ago
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

12 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Blocks: 256197
No longer blocks: 256195

Updated

12 years ago
Flags: testcase+

Updated

11 years ago
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.