419846 - (CVE-2008-2802) Non-chrome XUL documents can load chrome scripts from the fastload file

Status: RESOLVED FIXED

(Core :: Security, defect, P2)

Description

[moz_bug_r_a4]

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][[e-mail]]]

I suggest we prevent loading chrome .js from content.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(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]]

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]]

No, I can reproduce in a debug branch build, too.

Comment 6

[Daniel Veditz [:dveditz]]

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 [:bzbarsky]]

> or will that break too many extensions?

Can we get an AMO scan to answer that question?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(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)]

Attachment: 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 [:bzbarsky]]

Comment on attachment 308770 [details] [diff] [review]
Fix.

Looks reasonable at first glance...

Comment 11

[Johnny Stenback (:jst)]

Fix checked in.

Comment 12

[Johnny Stenback (:jst)]

Attachment: 1.8 branch fix.

Comment 13

[Daniel Veditz [:dveditz]]

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 - ex-MoCo]]

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]

>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 [:bzbarsky]]

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]

>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]

<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]

remote xbl loading chrome uris is Bug 443400

Comment 20

[Boris Zbarsky [:bzbarsky]]

georgi, the browser and global packages DO explicitly allow linking to them.  Please read comment 16 again?

Comment 21

[Alexander Sack]

Comment on attachment 323625 [details] [diff] [review]
1.8 branch fix.

a=asac for 1.8.0 branch