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.
Created attachment 267384 [details] testcase 1 - autoscroll This works on trunk, fx2.0.0.x and fx1.5.0.x.
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.
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?
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. :(
10 years ago
Fix checked in on the trunk.
Comment on attachment 267685 [details] [diff] [review] Possible fix. approved for 22.214.171.124 and 126.96.36.199, a=dveditz for release-drivers
Verified on Thunderbird version 188.8.131.52 (20070809) using testcases in comments 1, 2, 3 Also verified fixed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/2007071317 Firefox/220.127.116.11 Tbird 15012 and Fx2004 showed problem (dialogs came up), but Tbird 15013 and Fx2005 worked fine (no dialogs).