324074 - Chrome-privileged content does not get automatic wrappers

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Daniel Veditz [:dveditz]]

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

[Jesse Ruderman]

Yikes.  I made exactly this assumption with http://www.squarefree.com/extensions/thumbs/.

Comment 2

[Brendan Eich [:brendan]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

> 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

[[e-mail]]

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

Comment 5

[Brendan Eich [:brendan]]

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

Comment 6

[Daniel Veditz [:dveditz]]

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?

Comment 7

[Josh Aas]

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

Does this bug need to remain hidden?

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

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.