443400 - restructure chrome packaging to remove as many files as possible from content-accessible packages

Status: NEW

(Firefox :: General, defect)

Description

[georgi - hopefully not receiving bugspam]

Attachment: testcase bind7a.html

i see no reason remote content to be able to use:
<div style="-moz-binding: url('chrome://browser/locale/netError.dtd')">

dealing with chrome may cause security problems in theory

Comment 1

[Boris Zbarsky [:bzbarsky]]

What should be happening is that the chrome needs to be restructured so that only things that are really needed by external content are in external content packages.  We have the infrastructure for this in place; the ball is in the court of the folks who set up the chrome packaging, which is NOT Core:XBL.

Comment 2

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

"may cause security problems in theory" makes it hard to decide to invest a lot of effort into doing this, especially considering that we're always going to end up with *some* accessible chrome (at least for the foreseeable future).

Comment 3

[georgi - hopefully not receiving bugspam]

ok, i don't have an exploit for this. resolve the bug as you wish.

Comment 4

[Jesse Ruderman]

I think the plan in bug 546856 is better.

Comment 5

[Tom Ritter [:tjr]]

Is this still an issue with XBL removed?

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #5)

Is this still an issue with XBL removed?

I think Comment 1 is still accurate even with XBL gone:

What should be happening is that the chrome needs to be restructured so that
only things that are really needed by external content are in external
content packages. We have the infrastructure for this in place; the ball is
in the court of the folks who set up the chrome packaging, which is NOT
Core:XBL.

Though it seems possible that we've either (a) implemented changes with packaging in the meantime or (b) this isn't relevant anymore post XUL addon removal or based on other changes in the past decade. Mossop, do you think this bug should be closed?

Comment 7

[Dave Townsend [:mossop]]

As far as I can tell there are still lots and lots of chrome resources accessible to content. Whether that is something we still want to solve is probably up to the security team to decide. Worth considering that this is probably a method of fingerprinting the user if they have blocked other means, looking at the content of browser.js will probably give you a very accurate Firefox version.