792312 - Content scripts can mess with XBL scripts (with __proto__, defineProperty, etc)

Status: RESOLVED WORKSFORME

(Core :: XBL, defect)

Description

[Jesse Ruderman]

Attachment: testcase - splats some <marquee> anonymous content

Based on comments in bug 733305, I guess this might be a security problem?

Comment 1

[Jesse Ruderman]

Especially scary if |Components| is going to be protected only by scopes (see bug 790732).

Comment 2

[Bobby Holley (:bholley)]

(In reply to Jesse Ruderman from comment #1)
> Especially scary if |Components| is going to be protected only by scopes
> (see bug 790732).

To clarify, Components is also protected by a same-compartment security wrapper. Defense-in-depth there.

Comment 3

[Bobby Holley (:bholley)]

(In reply to Bobby Holley (:bholley) from comment #2)
> To clarify, Components is also protected by a same-compartment security
> wrapper. Defense-in-depth there.

(protected in the sense that only the things that are currently available to content - Ci, Components.lookupMethod, etc - will be available, even if content manages to get its hands on the object).

Comment 4

[Bobby Holley (:bholley)]

But yeah, hm. XBL scripts run with page principal, so traditionally it hasn't been considered a major problem is web content manages to muck with them. But now that we're doing the XBL thing, we don't really want them to be able to convince the XBL code to return |Components| off its scope chain. Can we think of any way that this could be used to do that?

Another thing to keep in mind is that XBL scripts are pseudo-privileged (even though they live in the content compartment) because they can see through SOWs. I wonder if that would be possible to exploit here.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, this sounds like a messy problem. The fact that we weren't giving XBL content any special privileges was always a nice security property.

Can we isolate the script which is running with extended privileges more narrowly than "all of XBL"?

Comment 6

[Bobby Holley (:bholley)]

(In reply to Jonas Sicking (:sicking) from comment #5)
> Can we isolate the script which is running with extended privileges more
> narrowly than "all of XBL"?

Nothing is really running with extended privileges - it's just the ability to touch all of the anonymous content inside <video> elements and such. I don't think there are any direct security issues we know of (since all that stuff still runs with page principal), but we'd still like to avoid it, and it also prevents content scripts from depending on our implementation of <video>

Also, a neat idea - in addition to putting the |Components| object on the XBL scope chain, we could also give it a SOW, meaning that only XBL scripts could touch it. We already have that infrastructure in place, so it'd be trivial.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Bobby Holley (:bholley) from comment #6)
> it's just the ability
> to touch all of the anonymous content inside <video> elements and such.
Native anonymous

Comment 8

[Bobby Holley (:bholley)]

(In reply to Olli Pettay [:smaug] from comment #7)
> (In reply to Bobby Holley (:bholley) from comment #6)
> > it's just the ability
> > to touch all of the anonymous content inside <video> elements and such.
> Native anonymous

I intentionally left of the "native" here, on the grounds that the video stuff is only artificially marked NAC. ;-)

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

video stuff is *explicitly* NAC ;)

Comment 10

[Andrew McCreight [:mccr8]]

Is this still a problem? If so, what sort of security rating should it get?
https://wiki.mozilla.org/Security_Severity_Ratings

Comment 11

[Bobby Holley (:bholley)]

I think smaug probably has a better idea here.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

This is still a problem. But unless we have broken the chrome:// security (pseudo privilege) checks, 
this shouldn't be any worse than exposing XBL to content (via <marquee>).

I wonder if we could mark <marquee>'s binding to be chromeOnlyContent. Then
if content page would inject something to the binding, it would be able to access it.
Testing...

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

chromeOnlyContent might of course help with only some problems.
If XBL could use XRays, that would be better, I think.

Comment 14

[Bobby Holley (:bholley)]

Cody, is there anything left here now that we have XBL scopes etc?

Comment 15

[Cody Crews]

I think we're good.  This week so far I've put in at least 10 hours just trying to compromise the XBL scopes of the only bindings that still expose anything to content.  So far, no dice.

There may be some issues with chrome level XBL bindings which I'm starting to audit right now(IIRC chrome level XBL runs same compartment).

There's some issues with the wrong element being focused but I can't see them being exploitable.  We're definitely good for now.

Comment 16

[Bobby Holley (:bholley)]

Ok. Thanks Cody!