|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
(Assignee)

Updated

13 years ago
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+
(Assignee)

Comment 7

13 years ago
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.
(Assignee)

Comment 8

13 years ago
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.
(Assignee)

Updated

13 years ago
Depends on: 281988
(Assignee)

Updated

13 years ago
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?
(Assignee)

Updated

13 years ago
Group: security
Keywords: fixed1.7.7
Whiteboard: [sg:fix] hold private until April 25,2005 → [sg:fix]

Comment 11

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

Comment 12

13 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

13 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
(Assignee)

Comment 14

12 years ago
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
(Assignee)

Updated

12 years ago
Blocks: 256197
(Assignee)

Updated

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