Closed
Bug 289083
Opened 20 years ago
Closed 20 years ago
|new Script()| causes arbitrary code execution
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: moz_bug_r_a4, Assigned: dveditz)
References
Details
(Keywords: fixed-aviary1.0.3, fixed1.7.7, Whiteboard: [sg:fix])
Attachments
(5 files)
357 bytes,
text/html
|
Details | |
684 bytes,
text/html
|
Details | |
1009 bytes,
text/html
|
Details | |
5.67 KB,
patch
|
jst
:
review+
jst
:
superreview+
dbaron
:
approval-aviary1.0.3+
dbaron
:
approval1.7.7+
|
Details | Diff | Splinter Review |
5.69 KB,
patch
|
Details | Diff | Splinter Review |
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•20 years ago
|
||
this requires user's click action.
Reporter | ||
Comment 2•20 years ago
|
||
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•20 years ago
|
||
this does not need user interaction. for Firefox 1.0+, Mozilla 1.8b
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•20 years ago
|
Flags: blocking1.7.7?
Flags: blocking-aviary1.0.3?
Comment 4•20 years ago
|
||
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+
Updated•20 years ago
|
Flags: blocking1.7.7?
Flags: blocking1.7.7+
Flags: blocking-aviary1.0.3?
Flags: blocking-aviary1.0.3+
Attachment #179827 -
Flags: approval1.7.7+
Attachment #179827 -
Flags: approval-aviary1.0.3+
Assignee | ||
Comment 7•20 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•20 years ago
|
||
Original testcases fixed by this patch, but see bug 289074 comment 13 and the testcase in attachment 179875 [details]
Comment 9•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Whiteboard: [sg:fix] hold private until April 25,2005
Comment 10•20 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•20 years ago
|
Comment 11•20 years ago
|
||
dan says bug 281988 superceedes this. unblocking 1.8b2.
Flags: blocking1.8b2+
Comment 12•20 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•20 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•20 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
Closed: 20 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Flags: testcase+
Updated•18 years ago
|
Flags: in-testsuite+ → in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•