Chrome-privileged content does not get automatic wrappers

RESOLVED FIXED

Status

()

Core
XPConnect
RESOLVED FIXED
12 years ago
5 years ago

People

(Reporter: dveditz, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox-esr10 unaffected)

Details

(Whiteboard: [sg:want] (extension sidebars vulnerable?))

(Reporter)

Description

12 years ago
content pages loaded from chrome: inherit chrome privilege (see bug 286651), but they do not get automatic xpcnativewrappers. Several extensions install normal sidebar panels to operate on content--loaded from chrome, of course. These must still manually wrap content nodes to interact safely but most extension authors either don't know about this requirement or assume the auto-wrapping mechanism takes care of it.

Comment 1

12 years ago
Yikes.  I made exactly this assumption with http://www.squarefree.com/extensions/thumbs/.
There may be a need to enhance the JS engine's APIs here, but this is not really a bug against XPConnect or JS -- it's a higher-level bug.  Questions:

1.  What causes content loaded from chrome to have chrome privileges?

2.  What container, e.g. <browser type="content">, is used?

3.  What URLs are loaded, arbitrary non-chrome: ones or more narrow URL types?

/be
> 1.  What causes content loaded from chrome to have chrome privileges?

The chrome registry sets the system principal on the document.

> 2.  What container, e.g. <browser type="content">, is used?

Exactly.  <browser type="content"> or <browser type="content-primary">

> Several extensions install normal sidebar panels

We shouldn't allow chrome documents to load in non-type-chrome sidebars, in my opinion.

We could also consider changing the setup described at http://developer.mozilla.org/en/docs/XPCNativeWrapper#What_is_a_trusted_window.3F

The problem there is that we need to flag the global object as trusted or not before we have any idea what's going to be loaded in the window.  So this seems to me to be a non-starter.

Would it be reasonable to only allow chrome to load in docshells that are content-primary or chrome?  That would mean no loading chrome in background tabs or sidebars.  For FF2 we could allow it in background tabs again if needed (since by then we will be able to tell a background tab apart from a sidebar).

Another option is to change the sidebar code to create chrome-type docshells for sidebars that are loaded from chrome://. Is that feasible?  I have no idea how the different (we have at least 2, maybe more?) sidebar impls work.

Comment 4

12 years ago
(In reply to comment #3)
>Another option is to change the sidebar code to create chrome-type docshells
>for sidebars that are loaded from chrome://. Is that feasible?  I have no idea
>how the different (we have at least 2, maybe more?) sidebar impls work.
Not an issue in suite, we load chrome: URLs in chrome browsers.
(Reporter)

Updated

12 years ago
Whiteboard: [sg:critical?] (extension sidebars vulnerable?)
This is outside the original design for XPCNativeWrapper automation.  I am not going to have time to deal with it.  I can advise ;-).  My first piece of advice (free :-P) is to outlaw chrome loading content.

/be
Assignee: brendan → nobody
(Reporter)

Comment 6

11 years ago
The vulnerability here is not in our code (at least not yet) but in potential future extension code or client code that makes this reasonable (but wrong) assumption. I guess it's not "critical"; is it a vulnerability at all (like "moderate") or simply a really good idea to fix?
Whiteboard: [sg:critical?] (extension sidebars vulnerable?) → [sg:want] (extension sidebars vulnerable?)

Comment 7

5 years ago
Blake - has anything happened to improve this situation since we last looked at this (2007)?

Does this bug need to remain hidden?
This was fixed for better or worse by brain transplants by making the wrapper automation be based on principal rather than the system bit/filename. The underlying issue still does exist in Firefox 3.6, so I'm not sure if we should hold off on opening this until that's EOLed.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
status-firefox-esr10: --- → unaffected
(Reporter)

Updated

5 years ago
Group: core-security
You need to log in before you can comment on or make changes to this bug.