Closed
Bug 419846
(CVE-2008-2802)
Opened 17 years ago
Closed 17 years ago
Non-chrome XUL documents can load chrome scripts from the fastload file
Categories
(Core :: Security, defect, P2)
Core
Security
Tracking
()
RESOLVED
FIXED
People
(Reporter: moz_bug_r_a4, Assigned: jst)
References
Details
(Keywords: testcase, verified1.8.1.15, Whiteboard: [sg:critical])
Attachments
(2 files)
1.09 KB,
patch
|
enndeakin
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
1018 bytes,
patch
|
dveditz
:
approval1.8.1.15+
asac
:
approval1.8.0.next+
|
Details | Diff | Splinter Review |
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•17 years ago
|
||
I suggest we prevent loading chrome .js from content.
Comment 3•17 years ago
|
||
(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]
Comment 4•17 years ago
|
||
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•17 years ago
|
||
No, I can reproduce in a debug branch build, too.
Comment 6•17 years ago
|
||
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•17 years ago
|
||
> or will that break too many extensions?
Can we get an AMO scan to answer that question?
Updated•17 years ago
|
Flags: blocking1.8.1.13? → blocking1.8.1.13+
Comment 8•17 years ago
|
||
(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•17 years ago
|
Flags: tracking1.9? → blocking1.9?
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Updated•17 years ago
|
Assignee: nobody → jst
Flags: blocking1.8.1.13+ → blocking1.8.1.14+
Assignee | ||
Comment 9•17 years ago
|
||
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 10•17 years ago
|
||
Comment on attachment 308770 [details] [diff] [review] Fix. Looks reasonable at first glance...
Attachment #308770 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Updated•17 years ago
|
Attachment #308770 -
Flags: review? → review?(enndeakin)
Updated•17 years ago
|
Attachment #308770 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 11•17 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite?
Assignee | ||
Comment 12•17 years ago
|
||
Attachment #323625 -
Flags: approval1.8.1.15?
Comment 13•17 years ago
|
||
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•17 years ago
|
Keywords: fixed1.8.1.15
Comment 14•17 years ago
|
||
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
Updated•16 years ago
|
Alias: CVE-2008-2802
Updated•16 years ago
|
Group: security
Comment 15•16 years ago
|
||
>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•16 years ago
|
||
georgi, that's already been done except for chrome packages that explicitly say they want to be linkable to from web content.
Updated•16 years ago
|
Version: unspecified → Trunk
Comment 17•16 years ago
|
||
>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•16 years ago
|
||
<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•16 years ago
|
||
remote xbl loading chrome uris is Bug 443400
![]() |
||
Comment 20•16 years ago
|
||
georgi, the browser and global packages DO explicitly allow linking to them. Please read comment 16 again?
Comment 21•16 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•16 years ago
|
Flags: blocking1.8.0.next+
You need to log in
before you can comment on or make changes to this bug.
Description
•