1499868 - BroadcastChannel may allow a compromises process to subscribe to another origin's messages

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Tom Ritter [:tjr] (OOTO until mid-August)]

I'm not certain this is the case, but it appears that the async ClearSiteDataReloadNeeded(nsString origin); on PContent.ipdl may be called on all content processes to inform them that they need to reload any tabs that contain a particular origin.

This informs other content processes about what other origins the user is currently browsing (albeit only if an origin sends the Clear-Site-Data header).

:baku - do I have my understanding right that as it is currently implemented; post-Fission we will be sending ClearSiteDataReloadNeeded to content processes other than the one that had its origin cleared?

Comment 1

[Andrea Marchesini [:baku]]

> :baku - do I have my understanding right that as it is currently
> implemented; post-Fission we will be sending ClearSiteDataReloadNeeded to
> content processes other than the one that had its origin cleared?

Correct. Post-Fission, this method has to be restricted. Same thing for BroadcastChannel and ReportingObserver (not landed yet).

Is there already a way to know which origins are loaded by which process?

Comment 2

[Tom Ritter [:tjr] (OOTO until mid-August)]

(In reply to Andrea Marchesini [:baku] from comment #1)
> > :baku - do I have my understanding right that as it is currently
> > implemented; post-Fission we will be sending ClearSiteDataReloadNeeded to
> > content processes other than the one that had its origin cleared?
> 
> Correct. Post-Fission, this method has to be restricted. Same thing for
> BroadcastChannel and ReportingObserver (not landed yet).
> 
> Is there already a way to know which origins are loaded by which process?

Not yet, Bug 1491018 is for that

Comment 3

[Andrea Marchesini [:baku]]

Couple of notes:

1. BroadcastChannel is a minor problem: we send messages only if there is an active actor in the content process, observing the wanted origin. Of course, if the content process is compromised, it can know that the current process is running that origin.

2. Clear-Site-Data: we broadcast a message to each process to reload a particular origin. A compromised process can know, by that, that there is, somewhere (maybe in another process) a tab loading that origin. Note that clear-site-data header can be received when loading sub-resources: it's not just for document requests.

3. reportingObserver: we don't broadcast data here. Reports are received by the current context only. They are also sent to the parent process in case there are some report-to endpoints. This is fine.

4. We have similar issues with ServiceWorkers. We do have a service-worker registration map in any process.

Comment 4

[Chris Peterson [:cpeterson]]

This bug is Fission Future post-MVP.

Comment 5

[Tom Ritter [:tjr] (OOTO until mid-August)]

I'm not sure exactly the state of the different components of this so it will need some re-validating; but from the given description we consider it a blocker for disabling Spectre mitigations.

Comment 6

[Tom Ritter [:tjr] (OOTO until mid-August)]

I filed Bug 1730197 for the Clear Site Data one. Investigating others.

Comment 7

[Tom Ritter [:tjr] (OOTO until mid-August)]

Looking at this again; BroadcastParent seems to look up the correct actors to message based on the recipient origin. This is safe; but what's uncertain to me per comment 3 is if we can broadcast to a different content process under some circumstances. Baku, do you know or could you redirect?

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

BroadcastChannel won't randomly send messages to uninterested processes. I think what :baku was trying to convey in comment 3 was:

1. A compromised process could request to open a BroadcastChannel for an origin that does not exist in that process and it would work because we currently have no validation absent a bug 1491018 fix. (Noting that the Clients API could provide coverage for this.)
2. Clear-Site-Data does leak information about the existence of origins which could allow a compromised process to proactively snoop on an informed basis. Not sure this still holds true; it certainly doesn't have to hold true with PWindowGlobal and the clients API existing.
3. (dunno)
4. The ServiceWorker thing no longer works the way it was described in comment 3, but comment 3 was describing a means of being able to know about a lot of interesting origins. (Although I suppose a rogue content process could perhaps create a PServiceWorkerManager which, if successful, would let it know about the existing origins with ServiceWorkers? We may want additional guards against that if we don't have them.)

Comment 9

[Tom Ritter [:tjr] (OOTO until mid-August)]

Based on that I'll move this to blocking out site sandboxing efforts rather than Spectre Mitigation Disabling