Last Comment Bug 289961 - DOMLinkAdded events synthesized by content can make chrome access non-DOM JS property "rel"
: DOMLinkAdded events synthesized by content can make chrome access non-DOM JS ...
Status: RESOLVED FIXED
[sg:fix] trunk covered by 289940
: fixed-aviary1.0.3, fixed1.7.7
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
: Brendan Eich [:brendan]
Mentors:
https://bugzilla.mozilla.org/attachme...
Depends on: 289940
Blocks: sbb+
  Show dependency treegraph
 
Reported: 2005-04-11 14:06 PDT by David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
Modified: 2007-04-01 14:39 PDT (History)
13 users (show)
chase: blocking1.7.7+
chase: blocking‑aviary1.0.3+
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (6.24 KB, patch)
2005-04-11 14:12 PDT, David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
jst: review+
jst: superreview+
chase: approval‑aviary1.0.3+
chase: approval1.7.7+
Details | Diff | Splinter Review

Description David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2005-04-11 14:06:52 PDT
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.
Comment 1 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2005-04-11 14:12:47 PDT
Created attachment 180411 [details] [diff] [review]
patch

This still needs testing...
Comment 2 Chase Phillips 2005-04-11 15:25:45 PDT
blocking-aviary1.0.3+
Comment 3 Chase Phillips 2005-04-11 15:26:36 PDT
Comment on attachment 180411 [details] [diff] [review]
patch

a=chase/drivers for the aviary1.0.1 branch pending r/sr
Comment 4 Chase Phillips 2005-04-11 15:28:30 PDT
Comment on attachment 180411 [details] [diff] [review]
patch

a=chase/drivers for the 1.7 branch pending r/sr
Comment 5 Johnny Stenback (:jst, jst@mozilla.com) 2005-04-11 15:58:51 PDT
Comment on attachment 180411 [details] [diff] [review]
patch

r+sr=jst
Comment 6 Chase Phillips 2005-04-11 16:17:33 PDT
retroactively setting blocking1.7.7+
Comment 7 Chase Phillips 2005-04-11 16:19:55 PDT
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] 2005-04-11 17:58:45 PDT
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) 2005-04-12 10:28:52 PDT
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) 2005-04-12 10:34:36 PDT
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] 2005-04-17 11:35:39 PDT
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] 2005-06-02 16:30:58 PDT
Not a trunk problem (fixed in other bugs)

Note You need to log in before you can comment on or make changes to this bug.