Bug 419846 (CVE-2008-2802)

Non-chrome XUL documents can load chrome scripts from the fastload file

RESOLVED FIXED

Status

()

Core
Security
P2
normal
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: moz_bug_r_a4, Assigned: jst)

Tracking

({testcase, verified1.8.1.15})

Trunk
testcase, verified1.8.1.15
Points:
---
Bug Flags:
blocking1.9 +
blocking1.8.1.15 +
wanted1.8.1.x +
blocking1.8.0.next +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical])

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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

9 years ago
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:1.8.1.13pre) Gecko/20080223 BonEcho/2.0.0.13pre , for some reason.
Flags: blocking1.9?
Flags: blocking1.8.1.13?
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:critical]
Keywords: testcase
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?
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.
Assignee: dveditz → nobody
Depends on: 292789
Flags: wanted1.8.1.x+
> or will that break too many extensions?

Can we get an AMO scan to answer that question?
Flags: blocking1.8.1.13? → blocking1.8.1.13+
(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

Updated

9 years ago
Flags: tracking1.9? → blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee: nobody → jst
Flags: blocking1.8.1.13+ → blocking1.8.1.14+
(Assignee)

Comment 9

9 years ago
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.
Attachment #308770 - Flags: superreview?(bzbarsky)
Attachment #308770 - Flags: review?
Comment on attachment 308770 [details] [diff] [review]
Fix.

Looks reasonable at first glance...
Attachment #308770 - Flags: superreview?(bzbarsky) → superreview+
(Assignee)

Updated

9 years ago
Attachment #308770 - Flags: review? → review?(enndeakin)

Updated

9 years ago
Attachment #308770 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 11

9 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
(Assignee)

Comment 12

9 years ago
Created attachment 323625 [details] [diff] [review]
1.8 branch fix.
Attachment #323625 - Flags: approval1.8.1.15?
Comment on attachment 323625 [details] [diff] [review]
1.8 branch fix.

Approved for 1.8.1.15, a=dveditz for release-drivers
Attachment #323625 - Flags: approval1.8.1.15? → approval1.8.1.15+
(Assignee)

Updated

9 years ago
Keywords: fixed1.8.1.15
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. 
Keywords: fixed1.8.1.15 → verified1.8.1.15
Alias: CVE-2008-2802
Group: security
>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.
Version: unspecified → Trunk
>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 21

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

a=asac for 1.8.0 branch
Attachment #323625 - Flags: approval1.8.0.next+

Updated

8 years ago
Flags: blocking1.8.0.next+
You need to log in before you can comment on or make changes to this bug.