1151001 - CPOWs vs. Sandboxing

Status: RESOLVED INCOMPLETE

(Core :: DOM: Content Processes, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

When desktop Firefox has content process sandboxing, CPOWs will gain some security implications they didn't previously have: a compromised content process can send arbitrary traffic over the PJavaScript protocol, which basically means it can turn any CPOW into an arbitrary proxy object that's not subject to XrayWrappers.  I'm reliably informed that chrome-privileged script trying to do things with non-Xrayed malicious objects is a rich source of non-obvious security mishaps, and compromised CPOWs would presumably be similar.

I don't know if anyone has evaluated Firefox's own usage of CPOWs in this light, and any add-on that uses CPOWs would have the potential to be a sandbox escape.

What, if anything (besides trying to get away from CPOWs), can we do about this?

Comment 1

[Bobby Holley (:bholley)]

Removing CPOW usage is more or less the only solution to this. In the mean time, we could audit CPOW usage (if we can identify it), and see if we find anything obvious.

Comment 2

[Bobby Holley (:bholley)]

Brad + others - I'm happy to sit down and talk with y'all in more detail about this and the addon issue if that would be helpful. Let me know.

Comment 3

[Bobby Holley (:bholley)]

One potential mitigation here is that the most common attacks against lack-of-Xrays are generally XSS-based, since they involve passing cross-origin objects (i.e. window and location) to chrome in a confusing way. Until we start having multiple content sandboxes, a child process exploit is universal XSS anyway, so we probably don't need to worry about those.

It would probably be good to severely limit the set of objects that can be held via a child->parent CPOW, which provides good defense against passing those objects back to the parent.

Comment 4

[Jim Mathies [:jimm]]

bill is this still an issue?

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm going to close this. No one has really articulated what additional exposure we have. I don't think XSS attacks are an issue because, as Bobby pointed out, those don't require a CPOW. And it's hard to see how this could be used for a sandbox escape. Parent-to-child CPOWs only return information. Child-to-parent CPOWs go through our existing chrome object wrappers, and those can't be bypassed with a content process exploit.

I'm not saying something bad won't happen, but none of the specific things that have come up seem problematic.