Without using overlay, non-chrome XUL documents can load chrome scripts from the fastload file by using <script> elements. This is exploitable in the same way as bug 390813.
I suggest we prevent loading chrome .js from content.
(In reply to comment #1) > Created an attachment (id=306012) [details] > testcase I can't reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20080223 BonEcho/126.96.36.199pre , for some reason.
I can reproduce on windows in both 188.8.131.52 release and a 20080227 184.108.40.206pre nightly. Would be interesting to see if there's some good reason why it's WFM for gavin. Was it a debug build? Do we disable caching in debug builds perhaps?
No, I can reproduce in a debug branch build, too.
Who should get this one? On the trunk this will be fixed by bug 292789; can we get away with that on the branch or will that break too many extensions? We can always pull the 2.0.1.x lever--that's what it's there for--but the pain of that might be worse than the original breakage.
> or will that break too many extensions? Can we get an AMO scan to answer that question?
(In reply to comment #4) > Would be interesting to see if there's some good reason why it's WFM for gavin. Not sure. Seems to trigger: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.href]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/nsDragAndDrop.js :: <TOP_LEVEL> :: line 540" data: no] This was with the latest branch nightly on Windows. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20080227 BonEcho/18.104.22.168pre
Created attachment 308770 [details] [diff] [review] Fix. I really don't know much about how our XUL prototype and fastload code works, so this could be way off. This fix essentially stops us from using the fastload cache for chrome scripts loaded from a non-chrome XUL document, and loading the scripts again in this case. The XUL prototype cache appears to be set up to not cache scripts loaded by a non-chrome XUL document already. The second part of this diff is what really fixes this bug, I'm not sure if the first check is necessary, but it seemed like the right thing to do.
Comment on attachment 308770 [details] [diff] [review] Fix. Looks reasonable at first glance...
Fix checked in.
9 years ago
Created attachment 323625 [details] [diff] [review] 1.8 branch fix.
Comment on attachment 323625 [details] [diff] [review] 1.8 branch fix. Approved for 22.214.171.124, a=dveditz for release-drivers
Verified bug reproduction with 126.96.36.199 and the fix for 188.8.131.52 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2008061005 BonEcho/220.127.116.11pre.
>I suggest we prevent loading chrome .js from content. agreed. i suggest killing 'chrome:' AND 'resource:' for all remote content including from xul overlays/bindings/styles. sure some web developers will whine and cry, but they'll get over it.
georgi, that's already been done except for chrome packages that explicitly say they want to be linkable to from web content.
>that's already been done except for chrome packages that explicitly say >they want to be linkable to from web content <div style="-moz-binding: url('chrome://global/content')">div</div> XML Parsing Error: no element found Location: jar:file:///opt/firefox-central/src/fb-opt-static/dist/bin/chrome/toolkit.jar!/content/global/global.xul Line Number 1, Column 1:
<div style="-moz-binding: url('chrome://browser/locale/netError.dtd')">div</div> XML Parsing Error: syntax error Location: jar:file:///opt/joro/firefox-central/src/fb-opt-static/dist/bin/chrome/en-US.jar!/locale/browser/netError.dtd Line Number 1, Column 1: <!ENTITY % brandDTD SYSTEM "chrome://branding/locale/brand.dtd"> ^ ###!!! ASSERTION: An XBL file is malformed. Did you forget the XBL namespace on the bindings tag?: 'Error', file /opt/joro/firefox-central/src/content/xbl/src/nsXBLService.cpp, line 1051
remote xbl loading chrome uris is Bug 443400
georgi, the browser and global packages DO explicitly allow linking to them. Please read comment 16 again?
Comment on attachment 323625 [details] [diff] [review] 1.8 branch fix. a=asac for 1.8.0 branch