Closed Bug 289961 Opened 16 years ago Closed 15 years ago

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

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: dbaron)

References

()

Details

(Keywords: fixed-aviary1.0.3, fixed1.7.7, Whiteboard: [sg:fix] trunk covered by 289940)

Attachments

(1 file)

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.
Flags: blocking-aviary1.0.3?
Attached patch patchSplinter Review
This still needs testing...
Attachment #180411 - Flags: superreview?(jst)
Attachment #180411 - Flags: review?(jst)
Attachment #180411 - Flags: approval-aviary1.0.3?
blocking-aviary1.0.3+
Flags: blocking-aviary1.0.3? → blocking-aviary1.0.3+
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 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+
retroactively setting blocking1.7.7+
Flags: blocking1.7.7+
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]
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.
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
Flags: blocking1.8b2+
Flags: blocking-aviary1.1+
Blocks: sbb+
Not a trunk problem (fixed in other bugs)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.