Last Comment Bug 419846 - (CVE-2008-2802) Non-chrome XUL documents can load chrome scripts from the fastload file
(CVE-2008-2802)
: Non-chrome XUL documents can load chrome scripts from the fastload file
Status: RESOLVED FIXED
[sg:critical]
: testcase, verified1.8.1.15
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on: 292789
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-27 07:37 PST by moz_bug_r_a4
Modified: 2009-01-05 11:43 PST (History)
13 users (show)
mbeltzner: blocking1.9+
dveditz: blocking1.8.1.15+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
jwalden+bmo: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix. (1.09 KB, patch)
2008-03-11 17:37 PDT, Johnny Stenback (:jst, jst@mozilla.com)
enndeakin: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
1.8 branch fix. (1018 bytes, patch)
2008-06-03 15:26 PDT, Johnny Stenback (:jst, jst@mozilla.com)
dveditz: approval1.8.1.15+
asac: approval1.8.0.next+
Details | Diff | Splinter Review

Description moz_bug_r_a4 2008-02-27 07:37:47 PST
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.
Comment 2 Olli Pettay [:smaug] 2008-02-27 07:44:40 PST
I suggest we prevent loading chrome .js from content.
Comment 3 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-02-27 08:08:09 PST
(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:1.8.1.13pre) Gecko/20080223 BonEcho/2.0.0.13pre , for some reason.
Comment 4 Daniel Veditz [:dveditz] 2008-02-27 10:57:44 PST
I can reproduce on windows in both 2.0.0.12 release and a 20080227 2.0.0.13pre 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?
Comment 5 Daniel Veditz [:dveditz] 2008-02-27 10:58:37 PST
No, I can reproduce in a debug branch build, too.
Comment 6 Daniel Veditz [:dveditz] 2008-02-27 11:03:38 PST
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.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2008-02-27 12:03:51 PST
> or will that break too many extensions?

Can we get an AMO scan to answer that question?
Comment 8 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-02-27 13:20:10 PST
(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:1.8.1.13pre) Gecko/20080227 BonEcho/2.0.0.13pre
Comment 9 Johnny Stenback (:jst, jst@mozilla.com) 2008-03-11 17:37:14 PDT
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 10 Boris Zbarsky [:bz] (still a bit busy) 2008-03-11 19:33:04 PDT
Comment on attachment 308770 [details] [diff] [review]
Fix.

Looks reasonable at first glance...
Comment 11 Johnny Stenback (:jst, jst@mozilla.com) 2008-03-13 15:49:59 PDT
Fix checked in.
Comment 12 Johnny Stenback (:jst, jst@mozilla.com) 2008-06-03 15:26:55 PDT
Created attachment 323625 [details] [diff] [review]
1.8 branch fix.
Comment 13 Daniel Veditz [:dveditz] 2008-06-04 11:30:29 PDT
Comment on attachment 323625 [details] [diff] [review]
1.8 branch fix.

Approved for 1.8.1.15, a=dveditz for release-drivers
Comment 14 Al Billings [:abillings] 2008-06-10 17:21:01 PDT
Verified bug reproduction with 2.0.0.14 and the fix for 2.0.0.15 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/2008061005 BonEcho/2.0.0.15pre. 
Comment 15 georgi - hopefully not receiving bugspam 2008-07-02 03:24:10 PDT
>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.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2008-07-02 10:22:46 PDT
georgi, that's already been done except for chrome packages that explicitly say they want to be linkable to from web content.
Comment 17 georgi - hopefully not receiving bugspam 2008-07-03 00:53:57 PDT
>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:
Comment 18 georgi - hopefully not receiving bugspam 2008-07-03 01:14:38 PDT
<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
Comment 19 georgi - hopefully not receiving bugspam 2008-07-03 05:52:45 PDT
remote xbl loading chrome uris is Bug 443400
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2008-07-03 09:39:11 PDT
georgi, the browser and global packages DO explicitly allow linking to them.  Please read comment 16 again?
Comment 21 Alexander Sack 2009-01-05 11:42:47 PST
Comment on attachment 323625 [details] [diff] [review]
1.8 branch fix.

a=asac for 1.8.0 branch

Note You need to log in before you can comment on or make changes to this bug.