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

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: moz_bug_r_a4, Assigned: jst)

Tracking

({verified1.8.0.13, verified1.8.1.5})

1.8 Branch
x86
Windows XP
verified1.8.0.13, verified1.8.1.5
Points:
---
Bug Flags:
blocking1.9 ?
blocking1.8.1.5 +
wanted1.8.1.x +
blocking1.8.0.13 +
wanted1.8.0.x +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical])

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
Created attachment 267384 [details]
testcase 1 - autoscroll

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

Comment 2

10 years ago
Created attachment 267385 [details]
testcase 2 - textZoom

This works on fx2.0.0.x, fx1.5.0.x, sm1.1.x and sm1.0.x.
Assignee: dveditz → nobody
Component: Security → DOM
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
QA Contact: toolkit → general
Whiteboard: [sg:critical]
Version: unspecified → 1.8 Branch
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.9?
Assignee: nobody → jst
(Assignee)

Comment 4

10 years ago
Created attachment 267685 [details] [diff] [review]
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?
Attachment #267685 - Flags: superreview?(bzbarsky)
Attachment #267685 - Flags: review?(mrbkap)
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.  :(
Attachment #267685 - Flags: superreview?(bzbarsky) → superreview+

Updated

10 years ago
Attachment #267685 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 6

10 years ago
Fix checked in on the trunk.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Attachment #267685 - Flags: approval1.8.1.6?
Attachment #267685 - Flags: approval1.8.1.5?
Attachment #267685 - Flags: approval1.8.0.14?
Attachment #267685 - Flags: approval1.8.0.13?
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
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
Attachment #267685 - Flags: approval1.8.1.6?
Attachment #267685 - Flags: approval1.8.1.5?
Attachment #267685 - Flags: approval1.8.1.5+
Attachment #267685 - Flags: approval1.8.0.14?
Attachment #267685 - Flags: approval1.8.0.13?
Attachment #267685 - Flags: approval1.8.0.13+
(Assignee)

Updated

10 years ago
Keywords: fixed1.8.0.13, fixed1.8.1.5

Comment 8

10 years ago
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).
Keywords: fixed1.8.0.13, fixed1.8.1.5 → verified1.8.0.13, verified1.8.1.5
Group: security
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.