1490461 - Enforce first-party isolation of alt-data created in the content process

Status: NEW

(Core :: Networking: Cache, enhancement, P3)

Description

[Luke Wagner [:luke]]

(Since any alt-data generated in the content process can be compromised if that site's process is compromised.)  Examples include the JS Bytecode Cache, wasm code caching (bug 1487113), and probably any other alt-data that shows up in the future.  This blocks bug 1484019 since it's not relevant until we have Fission.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

So, in addition to bug 1426353, when delivering alt-data, we should check which first-party origin generated the alt-data, and if we have a different origin requesting it, just send it the regular HTTP content?

I'm also wondering about scripts that get included all of over the place, such as analytics. Would it be a good idea in some situations generate the bytecode in the parent process?

Comment 2

[Honza Bambas (:mayhemer)]

This will likely ruin the whole positive performance effect of alt-data.  Except sharing scripts among sites from global cdns (jquery..) note that many sites are also split to 3rd level subdomains, each likely refers site specific scripts from some cdn-like or static.domain.tld paths.  Each visit and navigation between those subdomains will force us to throw away and regenerate (store) the alt-data again and again and again.  

As Valentin points out, scripts with higher *) frecency could be compiled on the parent (if possible?), something tells me there will be problems with that.

*) http cache keeps frecency (a relative number), which can be somewhat treated as time in the future.  We could have FRECENCY(now()+pref:threshold_period) to have a frecency threshold.

Comment 3

[Luke Wagner [:luke]]

(In reply to Valentin Gosu [:valentin] from comment #1)
> I'm also wondering about scripts that get included all of over the place,
> such as analytics. Would it be a good idea in some situations generate the
> bytecode in the parent process?

That could allow the alt-data to be uncorrupted by the rest of a compromised content process.  The only risk is if there was a vulnerability in the chars-to-bytecode since we're doing this in the parent process.  The other obvious option would be some separate, short-lived (maybe per-site) process.  And maybe this is only activated when a single resource gets shared by mutiple sites.

(In reply to Honza Bambas (:mayhemer) from comment #2)
> This will likely ruin the whole positive performance effect of alt-data. 
> Except sharing scripts among sites from global cdns (jquery..) note that
> many sites are also split to 3rd level subdomains, each likely refers site
> specific scripts from some cdn-like or static.domain.tld paths.  Each visit
> and navigation between those subdomains will force us to throw away and
> regenerate (store) the alt-data again and again and again.

Well, there's not an immediate need for this, b/c we won't have Fission for a while.  Do we have telemetry that indicates to us the degree to cross-site alt-data sharing?

Comment 4

[Nicolas B. Pierron [:nbp]]

For the JSBC, I think having the parent process generating the alt-data would be possible.  It would imply that instead of saving the bytecode, we would transmit the offsets of functions which have to be parsed eagerly by the parent process.

However, while this would prevent a corrupted content process from corrupting another content process, this would not prevent one from learning about the "hot" spots of the other webpages.

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Nicolas B. Pierron [:nbp] from comment #4)
> However, while this would prevent a corrupted content process from
> corrupting another content process, this would not prevent one from learning
> about the "hot" spots of the other webpages.

Hm. So it seems likely that we can extrapolate that attack into learning users other open tabs (including maybe recently closed ones) as well as some things about their activity on that site.  (If evil.com includes gmail.min.js, etc.)  That's pretty concerning. 

It also seems likely one could learn this data through a Spectre-only attack - the fact that the alt-data is present (or not) will be in memory in the Content Process, where it can be read - you don't need a native exploit to learn this info, just Spectre.  So that makes that design more concerning.

I think getting Telemetry on the degree to which users actually make use of cross-site alt-data sharing is a good plan. If that's a high degree then maybe we can try to figure out something more complicated to do to preserve that; but if it's negligible, then the simplest and safest thing won't really have a negative impact.

Comment 6

[Chris Peterson [:cpeterson]]

This bug is not a Fission MVP blocker.