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




14 years ago
12 years ago


(Reporter: dbaron, Assigned: dbaron)


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

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

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:fix] trunk covered by 289940, URL)


(1 attachment)

In bug 289074 comment 56, 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.

Comment 2

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

Comment 3

14 years ago
Comment on attachment 180411 [details] [diff] [review]

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

14 years ago
Comment on attachment 180411 [details] [diff] [review]

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

Attachment #180411 - Flags: superreview?(jst)
Attachment #180411 - Flags: superreview+
Attachment #180411 - Flags: review?(jst)
Attachment #180411 - Flags: review+

Comment 6

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

Comment 7

14 years ago
Comment on attachment 180411 [details] [diff] [review]

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.

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


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


14 years ago
Flags: blocking1.8b2? → blocking1.8b2+
Whiteboard: [sg:fix] → [sg:fix] hold private until April 25,2005
Whiteboard: [sg:fix] hold private until April 25,2005 → [patch] [sg:fix] hold private until April 25,2005
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


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


13 years ago
Flags: testcase+


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