383424 - Arbitrary code execution using an event handler attached to an element that is not in a document

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[moz_bug_r_a4]

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/events/src/nsEventListenerManager.cpp&rev=1.275&mark=1086-1088#1086
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsContentUtils.cpp&rev=1.218&mark=2403,2406-2408#2393

If aCurrentTarget is an element that is not in a document, nsCxPusher does not
push a JS context.  Because of this, when a content-registered event handler is
called, the subject principal can be the system principal, which can happen
when chrome modifies content DOM (e.g. appendChild(), setAttribute(), style.foo
= bar).  This allows content to run arbitrary code with chrome privileges. 
Also, the subject principal can be the safe context's principal (i.e. the
hidden window's principal).  In this case, since the hidden window's url is
resource://gre/res/hiddenWindow.html, and resource: is allowed to load chrome:
urls, if there is an XSS bug then content can run arbitrary code with chrome
privileges.

Comment 1

[moz_bug_r_a4]

Attachment: testcase 1 - autoscroll

This works on trunk, fx2.0.0.x and fx1.5.0.x.

Comment 2

[moz_bug_r_a4]

Attachment: testcase 2 - textZoom

This works on fx2.0.0.x, fx1.5.0.x, sm1.1.x and sm1.0.x.

Comment 4

[Johnny Stenback (:jst)]

Attachment: Possible fix.

This is tested and fixes the problem, but it's a two minute fix that didn't get much thought as to what side effects this might have. I'll want to think about this some more, but it seems like the right thing to do. Thoughts?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 267685 [details] [diff] [review]
Possible fix.

This is the right thing to do in general, I think, but we still have the problem that an element can outlive its owner document, in which case GetOwnerDoc() will return null.... I guess that can't happen if the element is being referenced from JS, though.

I really wish we had a principal stack, not a JSContext stack.  :(

Comment 6

[Johnny Stenback (:jst)]

Fix checked in on the trunk.

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 267685 [details] [diff] [review]
Possible fix.

approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers

Comment 8

[juan becerra [:juanb]]

Verified on Thunderbird version 1.5.0.13 (20070809) using testcases in comments 1, 2, 3

Also verified fixed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/2007071317 Firefox/2.0.0.5

Tbird 15012 and Fx2004 showed problem (dialogs came up), but Tbird 15013 and Fx2005 worked fine (no dialogs).