59701 - Need ability to execute trusted XBL/JS when doc is untrusted

Status: RESOLVED WONTFIX

(Core :: XBL, enhancement, P3)

Description

[Mike Pinkerton (not reading bugmail)]

For embedding of the html content area, we'd like to be able to attach XBL/JS
with the dragDrop handlers to the new window root node. However, this requires
that we be able to access XPConnect (for the drag service, etc) and the context
in which the XBL is inserted (the html content area) is untrusted.

Comment 1

[Mike Pinkerton (not reading bugmail)]

this blocks dnd for embedding.

Comment 2

[Brendan Eich [:brendan]]

Your component merely needs to implement nsISecurityCheckedComponent, and not
open any security holes (mstoltz should review the implementation closely!). 
See http://lxr.mozilla.org/mozilla/ident?i=nsISecurityCheckedComponent and DIY.

/be

Comment 3

[Mike Pinkerton (not reading bugmail)]

well, we can't bless the drag service. that would be a security violation. hyatt
says he'll own this.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Hyatt, please don't open any new interfaces to untrusted XPConnect access
without my review.

Comment 5

[Peter Trudelle]

moz0.9, but no requirement for embedding d&d yet.

Comment 6

[Peter Trudelle]

->future, per hyatt.

Comment 7

[Alex Fritze]

This bug is really limiting the usefulness of xbl for constructing new xml tags.
You can't even return 'Components.results.NS_ERROR_FAILURE' from a method, 
since Components.results is not security checked!

Has it been pushed back beyond 0.9 because it is technically difficult / 
timeconsuming or are there more fundamental security issues?

Comment 8

[Axel Hecht]

nsISecurityCheckedComponent is bad. Do the DOM class info instead.
But.
I wonder if something like baseURI should return the URI of the XBL file for
a binding instead of the document URI, so that could be used for security
checks.
IIRC, the baseURI isn't the document URI for entities as well, though I can't
paste the spec right now. If you want, I'll do that on tuesday.

Axel

Comment 9

[John Bandhauer]

BTW, Components.results.WHATEVER is now exposed to all scripts. I made this
change with mstoltz's approval as part of the xpcdom landing.

I disagree with the statement "nsISecurityCheckedComponent is bad". We want
something better. But nsISecurityCheckedComponent has the advantage of granular
access control. nsIClassInfo.DOM_OBJECT allows total access of all methods and
properties to all callers (and implies that the thing is a DOM object - even if
it is not). If improperly applied this is worse than bad.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

Yes, DOM_OBJECT should only be used for DOM objects - not as a convenient way to
make objects fully scriptable. Use nsISecurityCheckedComponent.

Comment 11

[Stuart Ballard]

Per discussion with Hyatt on n.p.m.xbl / n.p.m.security, I am posting this
description of a possible security model that would address this issue.

The Problem:
Intuitively it should be possible to add trusted code via bindings in html.css,
but because XBL uses the document's security principal, bindings to untrusted
html documents are untrusted.

The Proposed Solution:
Instead of using the security principal of the document, we use the security
principal of whatever makes the association from the document to the stylesheet.

The Rationale For The Solution:

There are three things that contribute to the intuitive fact that bindings from
html.css should be trusted:

1) html.css is trusted
2) The XBL file that it binds to is trusted
3) The association of html.css to the untrusted html file is done by a
   trusted entity - specifically, mozilla.

We can reduce this to the Proposed Solution above by applying the following logic:

#2 is irrelevant given #1, because if we trust the CSS file, we can
trust it not to bind to untrusted XBL; that would be Bloody Stupid.
#1 is irrelevant given #3, because we can trust the trusted entity here
to not be Bloody Stupid also.

So this boils down to trusting bindings if the person (principal) that
_makes_the_association_ from the document to the css file is trusted. Hence, the
XBL should be executed with this security principal.

There's an additional factor which suggests that this is a very reasonable model
and will not introduce security holes: In 99% of cases, this association comes
from a <link> or a <style src> or an <?xml-stylesheet?> in the document itself.
So in *all* of these cases, we've reduced the logic down to "The security
principal of the XBL and the CSS file is completely ignored, and the security
principal of the document is used". It reduces to the current model!

The *only* case where it doesn't reduce to the current model is when the
CSS file is attached implicitly by Mozilla, or (perhaps theoretically)
by some other trusted entity. This means, basically, html.css and very
little else :) I'm not sure exactly how html.css gets associated with HTML files
so I'm not sure whether there's an actual security principal floating around at
that point to be used. But if not, it would be easy to create and use a trusted one.

The cool thing about this solution is that it keeps the known-secure
model for 99.9% of cases, while also opening it up enough for every
single thing that I can imagine doing using XBL (they would *all*
involve using html.css). And it provides a clear rationale for *why* this is the
right thing to do.

Comment 12

[Stuart Ballard]

Oh, one other issue that came up during the discussion:

There is still a security hole if a document is able to access and modify/add
rules within html.css through the CSSOM. Nobody jumped into the discussion to
tell us whether this is currently true or not, but it seems reasonable to me not
to allow access to html.css at all through the CSSOM.

Comment 13

[Simon Fraser [no longer active]]

This would be useful in XBL for editable iframes too.

Comment 14

[Hixie (not reading bugmail)]

See also bug 177639 and bug 172673.

Comment 15

[Hixie (not reading bugmail)]

See also bug 177640.

Comment 16

[Benjamin Smedberg]

*** Bug 177660 has been marked as a duplicate of this bug. ***

Comment 17

[Benjamin Smedberg]

*** Bug 219637 has been marked as a duplicate of this bug. ***

Comment 18

[Benjamin Smedberg]

Not a blocker, I don't think ;)

Comment 19

[Hixie (not reading bugmail)]

Comment 11 seems sensible to me, assuming that we know that "trusted" bindings
in question have no way of being leveraged to breach security...

Comment 20

[Manko]

Transferring dependencies from bug 177660

Comment 21

[Manko]

My 2c: bindings in html.css should at least be able to read user prefs via
nsIPrefService. Especially for notorious <marquee> (see discussion at bug 163048).

Comment 22

[John L. Galt]

As this is a really really old bug and yet still marked new, (and it is one I voted on a long time ago) what should be done about it?

Comment 23

[Boris Zbarsky [:bzbarsky]]

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.