DOMLinkAdded events synthesized by content can make chrome access non-DOM JS property "rel"

RESOLVED FIXED

Status

()

Core
DOM: Events
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

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

Trunk
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] trunk covered by 289940, URL)

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
In bug 289074 comment 56, moz_bug_r_a4@yahoo.com wrote:
# And, if there is no real getter/setter, the user-defined getter/setter will
# be used. (Is this behavior benefited by unsafe_gsfun? if so, already fixed.)
# Thus, the following code can exploit.
#
#   // Body doesn't have |rel| property
#   document.body.__defineGetter__("rel", function() {
#     return { toString : new Script(code) };
#   });
#
#   var event = document.createEvent("Events");
#   event.initEvent("DOMLinkAdded", true, true);
#   document.body.dispatchEvent(event);

Testcase is attachment 180192 [details].


The real fix for this is bug 289940 (or bug 281988).  (Or perhaps also something
to caps -- I'm not sure why |new Script| can be used this way.)  But I'll attach
a patch here to fix just this one case, as we've already done for a bunch of
other cases, since bug 289940 is probably a bit much for 1.0.3.
(Assignee)

Updated

12 years ago
Flags: blocking-aviary1.0.3?
(Assignee)

Comment 1

12 years ago
Created attachment 180411 [details] [diff] [review]
patch

This still needs testing...
(Assignee)

Updated

12 years ago
Attachment #180411 - Flags: superreview?(jst)
Attachment #180411 - Flags: review?(jst)
Attachment #180411 - Flags: approval-aviary1.0.3?

Comment 2

12 years ago
blocking-aviary1.0.3+
Flags: blocking-aviary1.0.3? → blocking-aviary1.0.3+

Comment 3

12 years ago
Comment on attachment 180411 [details] [diff] [review]
patch

a=chase/drivers for the aviary1.0.1 branch pending r/sr
Attachment #180411 - Flags: approval-aviary1.0.3? → approval-aviary1.0.3+

Comment 4

12 years ago
Comment on attachment 180411 [details] [diff] [review]
patch

a=chase/drivers for the 1.7 branch pending r/sr
Attachment #180411 - Flags: approval1.7.7+
Comment on attachment 180411 [details] [diff] [review]
patch

r+sr=jst
Attachment #180411 - Flags: superreview?(jst)
Attachment #180411 - Flags: superreview+
Attachment #180411 - Flags: review?(jst)
Attachment #180411 - Flags: review+
(Assignee)

Updated

12 years ago
Keywords: fixed-aviary1.0.3, fixed1.7.7

Comment 6

12 years ago
retroactively setting blocking1.7.7+
Flags: blocking1.7.7+

Comment 7

12 years ago
Comment on attachment 180411 [details] [diff] [review]
patch

dbaron landed this on the aviary1.0.1 and 1.7 branches.
dbaron, I patched the JS engine (not caps) to add extra defense in the way of a
rogue (content) eval or Script.prototype.exec that has somehow managed to run on
a chrome (actually, any different-principals-pointer-owning) scope.  See bug
289074 attachment 180435 [details] [diff] [review].

This *could* break a web app distributed across several sub-domains that uses
document.domain and runs otherWindow.eval, but I'll take that chance.

/be
Flags: blocking1.8b2?
Flags: blocking-aviary1.1+
Whiteboard: [sg:fix]

Updated

12 years ago
Component: XP Miscellany → DOM: Events
when I load the test case in today's build (200504120x-1.0.3 ffox in linux fc3
and mac os x), all I get is a blank page. is this now expected behavior?
duh, to answer my own question: yes, looks fixed, since the exploit popup
doesn't appear. verified as fixed with 1.0.3 branch builds.

Updated

12 years ago
Flags: blocking1.8b2? → blocking1.8b2+
Whiteboard: [sg:fix] → [sg:fix] hold private until April 25,2005
(Assignee)

Updated

12 years ago
Whiteboard: [sg:fix] hold private until April 25,2005 → [patch] [sg:fix] hold private until April 25,2005

Comment 11

12 years ago
Has this landed on the trunk yet? Does it belong on the trunk? If so, can we
resolve it? If not, can we get it landed there?
Group: security
Whiteboard: [patch] [sg:fix] hold private until April 25,2005 → [sg:fix]
Depends on: 289940
Whiteboard: [sg:fix] → [sg:fix] trunk covered by 289940

Updated

12 years ago
Flags: blocking1.8b2+
Flags: blocking-aviary1.1+
Blocks: 256197
Not a trunk problem (fixed in other bugs)
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

11 years ago
Flags: testcase+

Updated

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