Opt-in Spectre Mitigation Strategies - Invitation to comment
Charles Reis (via Google Docs)
Hi all--I've been trying to catch up on the various proposals and fit them into a picture of how they would mitigate Spectre for different types of sites. It appears that we have many of the building blocks we need, though the important category of sites like Google and Facebook (e.g., OAuth providers) faces some tough challenges.
I put together this doc to evaluate the proposals for each type of site. Our team also thought about one approach that could work even for OAuth providers. Please take a look and let us know what you think would and wouldn't work. (Let me know if others need access to the doc; everyone here should have comment/suggestion access.)
As noted in the doc, these proposals focus on the bare minimum for Spectre protection. As Artur has mentioned, it may make sense to use this as a starting point and try to get additional protections as well, to increase the chances of adoption.
Thanks!
Charlie
Opt-in Spectre Mitigation Strategies
Charlie Reis, 5-2-2018
This document considers a few variations of opt-in approaches that sites could use to protect themselves from Spectre attacks, particularly in browsers that support cross-process navigations but not out-of-process iframes. The discussion below identifies challenges for many types of realistic sites (e.g., OAuth providers, maps, videos) where some form of embedding within untrusted pages seems to be a requirement.
Note that this document only focuses on the minimum required for mitigating Spectre, and not other potential benefits that might increase the likelihood that web developers will adopt the proposals. This can hopefully provide some baselines or ways to reason about improved proposals.
1. No cross-site iframes or embedding.
2. Cross-site iframes but no embedding.
3. Allow embedding in trusted pages.
4. Allow embedding in untrusted pages.
Site Categories
There are a few different categories of sites that are worth considering, since they face different tradeoffs for adopting opt-in Spectre mitigations:
- Sites with no cross-site iframes and no embedding requirements.
The approach for this is easy to reason about, but this category includes only the simplest sites. - Sites with cross-site iframes but no embedding requirements.
This should be possible to support with a few web-visible tradeoffs. This category probably includes some realistic sites with user accounts, such as banks or simple web apps. - Sites that must be embedded as iframes in trusted cross-site pages.
This could be supported with some trust relationships with the cross-site pages that are allowed to embed the site. Ideally this category would include cases like OAuth providers, but in practice that seems unlikely: it appears OAuth providers do not establish trust relationships with the sites that use them. - Sites that must be embedded in untrusted cross-site pages.
This is the hardest case to support. It is almost intractable without out-of-process iframes, if credentialed content is loaded into iframes on potentially malicious pages. Larger web-visible tradeoffs might need to be considered, like omitting credentials in iframes. This category includes things like maps, videos, and (unfortunately) OAuth providers. Sites like Google and Facebook likely fall here.
I would argue that we should try to support even the hardest category, since it includes sites that arguably need the Spectre protections the most.
Threat Model
Consider an attacker on evil.com who wants to exfiltrate data from a.com using Spectre, by getting a.com's documents or resources to share a process with it. For the more interesting categories of sites above, assume that a.com chooses to embed iframes from b.com, and that it trusts c.com to embed it.
Mitigation Strategies
As noted above, the strategies considered here for mitigating Spectre assume that the browser can swap processes on top-level navigations (and ideally support postMessage between processes).
We are aiming for approaches that could upgrade gracefully if out-of-process iframe support is added to browsers, even if only used to isolate certain sites. The protection should further upgrade gracefully if all sites are isolated (as Chrome is attempting).
This section considers approaches that could work for each of the site categories described above.
1. No cross-site iframes or embedding.
In this simplest category, a.com could fully protect itself using a From-Origin: SameSite header on every resource. From-Origin would have the following effects on browser behavior:
- It would enable X-Frame-Options-like iframe restrictions for the resource.
- It would enable CORB protections for the resource.
- It would force a process swap to a "restricted process" for a.com on any top-level navigation, and it would force a process swap to a different process when leaving a.com on any top-level navigation.
There would be no concerns with broken iframe/popup scripting, because a.com can't embed cross-site iframes or be embedded by cross-site iframes. It is always safe to do a cross-process navigation when entering or leaving a.com.
Attacks:
- evil.com loads a.com in an iframe.
Blocked, since From-Origin behaves like XFO. - evil.com loads a.com in an img tag.
Blocked, since From-Origin enables CORB. - evil.com loads a.com via window.open.
Forces a process swap. As long as the browser has support for cross-process postMessage (etc), leaving window.opener and window references in place should be fine. The two windows are cross-site and share no same-origin iframes, so they cannot ever script each other directly.
The strategy above says to use From-Origin on all resources. Technically the header would only be needed on:
- All resources (of any type) that actually contain sensitive data.
- All HTML documents that might ever load sensitive data (e.g., document.cookie, localStorage, password forms, CSRF tokens, etc, etc).
However, it seems hard to guarantee that an HTML document won't ever load sensitive data, and making exceptions might lead to tricky cases with same-origin frames living in different processes. Thus it seems strongly desirable to put the header on at least all HTML documents, plus all resources that have sensitive data. It should be safe to omit from subresources with no sensitive data (e.g., JavaScript, images, CSS, etc).
2. Cross-site iframes but no embedding.
Supporting this category would be similar to the first strategy, although allowing trusted b.com iframes within a.com does complicate the process model. a.com would do all the same things as before, but now it embeds iframes to b.com.
Consider the following example: a user visits document B1 on b.com, and then B1 does a window.open to document A1 on a.com (which contains iframe B2). At this point B1 might try to synchronously script document B2 within the iframe of A1. Browsers would need to do a process swap when opening A1 in a new window since B1 is in an unrestricted process, but this would break same-origin scripting between B1 and B2.
To avoid this problem, we could consider using rniwa@'s proposed Cross-Origin-Isolate header for all of a.com's resources, such that B1 and B2 have no window references to each other. (For comparison, Chrome's implementation could support this by means of a "BrowsingInstance" swap.)
In the reverse direction, suppose the B2 iframe within A1 tries to open a popup to top-level page B3. b.com's pages have no Cross-Origin-Isolate headers, so B3 must stay in a.com's restricted process, allowing B2 and B3 to script each other. This is different behavior than above and seems acceptable, because we're starting from a restricted process and we already trust b.com not to run a Spectre attack.
In other words, restricted processes are somewhat "sticky." Browsers would do a process swap when entering a.com from a cross-site page and when navigating away, but not when a cross-site iframe within a.com opens a popup to its own site.
Otherwise, all the same properties from the first approach seem to apply.
3. Allow embedding in trusted pages.
If a.com has a trust relationship with c.com and wants to let c.com embed its pages as iframes, this would require a few extra steps:
- a.com's From-Origin headers must list c.com.
Note that this list could get very long if a.com allows embedding in many other sites. Maybe the Sec-Site request header would make it possible for a.com to see the request is coming from c.com, and thus only list c.com in the From-Origin response header? - c.com MUST have its own From-Origin protections.
Without this, c.com could be sharing a process with evil.com, which would put an a.com iframe within c.com at risk. - The "restricted process" for c.com would be allowed to load a.com iframes and popups, since a.com's From-Origin header includes c.com.
It is important that unrestricted processes or processes restricted to other sites still cannot load a.com iframes. Also, if an a.com iframe opens a popup, it should stay in the c.com process so that the iframe and popup can script each other.
Attacks:
- evil.com loads c.com in an iframe or via window.open.
This is blocked under the assumption that c.com has its own From-Origin headers on all resources. If c.com failed to put From-Origin on all its documents, perhaps browsers could refuse to load the a.com iframes in c.com's documents, since a.com's From-Origin header would limit what can load in an unrestricted process. - evil.com has its own From-Origin header, possibly including a.com.
This means evil.com is now loaded in a restricted process rather than an unrestricted one. However, the browser still does not allow a.com iframes or popups to load in it because a.com's own From-Origin does not list evil.com.
This approach could be feasible to deploy if trust relationships existed with the sites a.com wants to be embedded within. Unfortunately, as noted above it seems unlikely this would work for OAuth providers or many other popular sites, which don't seem to have such trust relationships with embedders. (It may still be useful to build this support for sites that fall into this category and don't want the credential tradeoffs discussed below.)
4. Allow embedding in untrusted pages.
It seems essentially impossible to let a.com load credentialed iframes within fully untrusted sites in browsers without out-of-process iframes, although this is what many sites expect today: OAuth providers, Google Maps, YouTube, etc. Allowing these sites to protect themselves from Spectre is challenging and may require some larger tradeoffs.
lukasza@ suggests an approach where a.com iframes could be allowed to load in untrusted pages without credentials. For example, the browser could request the a.com document as usual (with credentials) for an iframe on evil.com. If the response comes back with a From-Origin header excluding evil.com, then the browser realizes it can't deliver it to the unrestricted process as is. The browser would cancel and reissue the request without credentials, allowing the (hopefully) non-sensitive content within the iframe. This does not address attacks that use ambient authority (e.g., intranet URLs), but it would allow sites like Maps and YouTube to work with a slightly degraded experience (i.e., not logged in).
For OAuth providers, the non-credentialed iframe would try to open a popup to a.com to let the user log in. There are two ways this could be supported:
- It could cause a process swap to a.com's restricted process, where credentials could be used safely. Given the process swap, a.com's popup couldn't use same-origin scripting to communicate back to its own a.com iframe, but in theory the OAuth provider could update its flow to use postMessage across the process boundary to pass the token and continue working. We would need to see if this is an acceptable tradeoff to OAuth providers.
- Instead of using credential-less iframes, browsers could use doubly-keyed cookies. This would allow the a.com popup to stay in the evil.com process and not share the same cookie store as normal a.com pages. Unfortunately, this is not an effective option for security. The user will still try to log into a.com in the evil.com process, exposing their password to evil.com's Spectre attack. While this approach requires fewer changes from OAuth providers, it does not provide sufficient Spectre mitigation.
Since using non-credentialed iframes would be a degraded experience for a.com, it would be desirable to let browsers transparently upgrade to credentialed iframes as soon as they have support for out-of-process iframes. Such browsers would not need to give *all* sites dedicated processes. Instead, they would just give fully dedicated processes to sites that have From-Origin headers, using out-of-process iframes when needed. This keeps the expected process count low, relative to a "isolate all sites" policy. (This would be similar to Chrome's IsolateOrigins policy, but allow sites themselves to request dedicated processes.)
If a browser does choose to isolate all sites, then the From-Origin headers remain useful to identify which resources should be protected by CORB (beyond the ones that CORB tries to infer using HTML, XML, and JSON with nosniff or confirmation sniffing).
Other options?
Apart from non-credentialed iframes, it's unclear if there are other viable approaches for this category of sites. In theory sites like Google Maps or YouTube could try to load with credentials without bringing any sensitive info in the iframe (e.g., supporting a "Watch Later" link using HttpOnly cookies). It seems highly unlikely that they could avoid loading any sensitive info into the process, though, given the wide range of data that might leak (e.g., CSRF tokens).
The non-credentialed approach does have some parallels with the App Isolation paper, but even the App Isolation approach would let the user log in inside the untrusted app's process (with the same drawbacks as the doubly-keyed cookies approach).
Summary
It seems that a combination of From-Origin, CORB, top-level cross-process navigations, and non-credentialed iframes might make it possible to offer Spectre mitigations to most sites that need it. The main caveat is that sites would have to deal with non-credentialed iframes when loaded in pages they do not have trust relationships with, posing some functionality challenges.
| Google Docs: Create and edit documents online. Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this email because someone shared a document with you from Google Docs. |  |