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

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In bug 289074 comment 56, [e-mail] 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 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This still needs testing...

Comment 2

[Chase Phillips]

blocking-aviary1.0.3+

Comment 3

[Chase Phillips]

Comment on attachment 180411 [details] [diff] [review]
patch

a=chase/drivers for the aviary1.0.1 branch pending r/sr

Comment 4

[Chase Phillips]

Comment on attachment 180411 [details] [diff] [review]
patch

a=chase/drivers for the 1.7 branch pending r/sr

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 180411 [details] [diff] [review]
patch

r+sr=jst

Comment 6

[Chase Phillips]

retroactively setting blocking1.7.7+

Comment 7

[Chase Phillips]

Comment on attachment 180411 [details] [diff] [review]
patch

dbaron landed this on the aviary1.0.1 and 1.7 branches.

Comment 8

[Brendan Eich [:brendan]]

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

Comment 9

[sairuh (rarely reading bugmail)]

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?

Comment 10

[sairuh (rarely reading bugmail)]

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.

Comment 11

[Asa Dotzler [:asa]]

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?

Comment 12

[Daniel Veditz [:dveditz]]

Not a trunk problem (fixed in other bugs)