1137947 - Verify Shumway's outermost sandbox

Status: RESOLVED INCOMPLETE

(Firefox Graveyard :: Shumway, defect)

Description

[Till Schneidereit [:till]]

This is the most important sandbox by far, as it prevents content from doing things that normal web content can't do in an uncontrolled manner. It's defined in the ShumwayCom.jsm module[1]. It passes in capabilities via an object with functions exported using exportFunction.

Bobby, you probably need additional information before you can start reviewing this, so we should schedule a meeting to go over the architecture.

[1] https://github.com/mozilla/shumway/blob/master/extension/firefox/chrome/ShumwayCom.jsm

Comment 1

[Bobby Holley (:bholley)]

I had a video call with mbx and yury today about this. I gave some feedback, and they're going to take a look at things and get back to me.

Comment 2

[Yury Delendik (:yury)]

https://github.com/mozilla/shumway/wiki/Outer-Sandbox-Security

Comment 3

[Till Schneidereit [:till]]

The feedback mentioned in comment 1 has been addressed. Additionally, Yury wrote extensive documentation about our sandboxing, linked to in comment 2.

Bobby, do you think this is in a reviewable state now? We could come down to MV next week (or you up to SF) to kick things off, if that works for you.

Comment 4

[Bobby Holley (:bholley)]

My biggest concern in comment 1 was the whole "running SWFs from different domains in the same compartment". Has that been addressed in a substantive way?

Per email, I'll be in SF on Wednesday, so we can meet then.

Comment 5

[Till Schneidereit [:till]]

(In reply to Bobby Holley (:bholley) from comment #4)
> My biggest concern in comment 1 was the whole "running SWFs from different
> domains in the same compartment". Has that been addressed in a substantive
> way?

We're currently working on a huge project to support SecurityDomains. In theory, that is what's needed to support running multiple SWFs in the same compartment in a safe manner. In practice, we'll very likely not be able to get this to a state where we have sufficient confidence in it being correct before 1.0.

Our plan for dealing with this is to largely punt on it. We think we can get away with that by exploiting two simplifying assumptions:

1. Banner ads very rarely load child SWFs from other domains. If they do, in all cases we could find they loaded them from domains that had crossdomain.xml files allowing the initial SWF to load arbitrary data from that domain. That means that they could've just loaded the SWF as bytes and executed it in their own domain, obviating the need for SecurityDomain. There's a difference in privileges there: the child SWF wouldn't be running in the security context of its original domain if it were loaded as bytes and then evaluated in another domain, so it couldn't load data from its original domain without a crossdomain.xml. That is ok, because we have already established that we do have such a crossdomain.xml file.

2. 1) above protects the loaded SWF from being accessed from the loading one in an insecure manner. That leaves the other direction. In pretty much all real-world cases, the protections gained through SecurityDomain are immediately given up on by using System.Security.allowDomain('*'). When we load a SWF from another domain, we check if the loading SWF has called System.Security.allowDomain('*'). If not, we reject the load, so the loading SWF cannot be compromised because of bugs in our SecurityDomain implementation.

Note that these two mitigations only work because of specific characteristics of banner ads. If and when we start targeting other content, we'll probably have to lose them. For now, this should cover the security concerns in a manner that doesn't break the content we care about, though.

Comment 6

[Bobby Holley (:bholley)]

We discussed this all in person on Wednesday.

Comment 7

[Till Schneidereit [:till]]

Bugs that block m3 don't need to also block m4.