Round-up of isolation / anti-Spectre proposals

[Artur Janc]

Hey all,

After the meetings last week I figured I'd try to summarize (mostly for myself) the state of the major mechanisms meant to protect from speculative execution attacks. My goal is to better understand the web-facing properties of the new proposals to get a sense of their adoption considerations, and the security benefits they will offer to application developers.

As I understand it, we're considering 3 classes of mechanisms:

1. Protections at the window level

Main goal: Allow an application to break opener relationships to/from its windows (possibly with exemptions for postMessage), enabling browsers without full Site Isolation to open these windows in a separate process.

Mechanisms: COWP, parts of Mozilla's / Nika's X-Bikeshed-* proposal, and deprecated features such as CSP3's disown-opener. These seem largely similar so we should pick a common approach and figure out where to put it (a separate response header, FP, CSP, or something else)

Web-facing security benefits: In addition to allowing browser's to add process-based isolation for the window, this would protect applications from several classes of cross-origin information leaks: vulnerabilities based on counting window.frames, tabnabbing, and some variants of XS-Search and Silhouette attacks.

2. Protections at the resource level

Main goal: Protect authenticated responses from being exposed to processes owned by non-cooperating origins -- prevent evil.com from being to load the bytes of victim.com/sensitive into its address space where it can be exfiltrated via speculative execution.

Mechanisms: CORB (by default); CORP / Sec-Metadata / Same-site cookies (opt-in). These are largely complementary so there is benefit to implementing several/all of them.

Web-facing security benefits: Potential to protect against large classes of endemic web bugs (CSRF, XSSI, clickjacking, timing attacks), but the defensive properties and adoptability vary significantly depending on the proposal (covered to some extent in the Spilling the beans paper.)

3. Restrictions on windows which want to use mechanisms that can serve as high-resolution timers 

Main goal: Allow applications to use SharedArrayBuffer and WASM threads even in browsers which don't support full process-based isolation, without letting these applications execute reliable Spectre-like attacks on other origins. In other words, unblock SABs for the web.

Mechanisms: "COWP level 2"; also touched upon in the X-Bikeshed proposal.

Web-facing security benefits: This could potentially turn into a broader sandbox-like mode where web applications get access to more powerful features at the cost of conforming to certain restrictions (e.g. requiring all fetches to be in CORS mode).

*

My understanding is that browsers with process-based site isolation will still need to implement the resource-level protections from #2 (CORB by default, and Sec-Metadata/CORP as opt-in mechanisms to protect remaining resource types from leaking across origins). Browsers without full site isolation will need to additionally implement #1. Arguably, all browsers might want to consider gating SABs on the implementation of #3, but there's a little more nuance to this.

Nika / Ryosuke / others, is this roughly in line with how you were thinking about this problem space?

Cheers,

-Artur

PS. I'm not sure if isolatio...@chromium.org is still the best place to discuss this. If anyone knows of any other folks/groups who might be interested in this (e.g. the Edge team), feel free to add them directly.

[Luke Wagner]

On Thu, Sep 27, 2018 at 4:38 AM 'Artur Janc' via isolation-policy <isolatio...@chromium.org> wrote:

Hey all,

After the meetings last week I figured I'd try to summarize (mostly for myself) the state of the major mechanisms meant to protect from speculative execution attacks. My goal is to better understand the web-facing properties of the new proposals to get a sense of their adoption considerations, and the security benefits they will offer to application developers.

As I understand it, we're considering 3 classes of mechanisms:

1. Protections at the window level

Main goal: Allow an application to break opener relationships to/from its windows (possibly with exemptions for postMessage), enabling browsers without full Site Isolation to open these windows in a separate process.

Mechanisms: COWP, parts of Mozilla's / Nika's X-Bikeshed-* proposal, and deprecated features such as CSP3's disown-opener. These seem largely similar so we should pick a common approach and figure out where to put it (a separate response header, FP, CSP, or something else)

Web-facing security benefits: In addition to allowing browser's to add process-based isolation for the window, this would protect applications from several classes of cross-origin information leaks: vulnerabilities based on counting window.frames, tabnabbing, and some variants of XS-Search and Silhouette attacks.

2. Protections at the resource level

Main goal: Protect authenticated responses from being exposed to processes owned by non-cooperating origins -- prevent evil.com from being to load the bytes of victim.com/sensitive into its address space where it can be exfiltrated via speculative execution.

Mechanisms: CORB (by default); CORP / Sec-Metadata / Same-site cookies (opt-in). These are largely complementary so there is benefit to implementing several/all of them.

Web-facing security benefits: Potential to protect against large classes of endemic web bugs (CSRF, XSSI, clickjacking, timing attacks), but the defensive properties and adoptability vary significantly depending on the proposal (covered to some extent in the Spilling the beans paper.)

3. Restrictions on windows which want to use mechanisms that can serve as high-resolution timers 

Main goal: Allow applications to use SharedArrayBuffer and WASM threads even in browsers which don't support full process-based isolation, without letting these applications execute reliable Spectre-like attacks on other origins. In other words, unblock SABs for the web.

Mechanisms: "COWP level 2"; also touched upon in the X-Bikeshed proposal.

Web-facing security benefits: This could potentially turn into a broader sandbox-like mode where web applications get access to more powerful features at the cost of conforming to certain restrictions (e.g. requiring all fetches to be in CORS mode).

*

With regards to:

 

My understanding is that browsers with process-based site isolation will still need to implement the resource-level protections from #2 (CORB by default, and Sec-Metadata/CORP as opt-in mechanisms to protect remaining resource types from leaking across origins). Browsers without full site isolation will need to additionally implement #1. Arguably, all browsers might want to consider gating SABs on the implementation of #3, but there's a little more nuance to this.

Because of the Web-facing security benefits you listed, which are independent of full site isolation, it seems like all browsers would want to implement #1.

Also, for the record, in a previous thread, we were and are in favor of doing what you suggested and having all browsers gate SABs on (some variant of) #3.  Now that Chrome has unconditionally enabled SAB on desktop, though, it seems like that ship has sailed.

Nika / Ryosuke / others, is this roughly in line with how you were thinking about this problem space?

Cheers,

-Artur

PS. I'm not sure if isolatio...@chromium.org is still the best place to discuss this. If anyone knows of any other folks/groups who might be interested in this (e.g. the Edge team), feel free to add them directly.

--
You received this message because you are subscribed to the Google Groups "isolation-policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isolation-poli...@chromium.org.
To post to this group, send email to isolatio...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/isolation-policy/CAPYVjqpHzetf4YmHoXM8fV4K3xbUKtiXQQwqwcDyKmvUnCUHHA%40mail.gmail.com.

[Artur Janc]

On Thu, Sep 27, 2018 at 6:50 PM Luke Wagner <lwa...@mozilla.com> wrote:

On Thu, Sep 27, 2018 at 4:38 AM 'Artur Janc' via isolation-policy <isolatio...@chromium.org> wrote:

Hey all,

After the meetings last week I figured I'd try to summarize (mostly for myself) the state of the major mechanisms meant to protect from speculative execution attacks. My goal is to better understand the web-facing properties of the new proposals to get a sense of their adoption considerations, and the security benefits they will offer to application developers.

As I understand it, we're considering 3 classes of mechanisms:

1. Protections at the window level

Main goal: Allow an application to break opener relationships to/from its windows (possibly with exemptions for postMessage), enabling browsers without full Site Isolation to open these windows in a separate process.

Mechanisms: COWP, parts of Mozilla's / Nika's X-Bikeshed-* proposal, and deprecated features such as CSP3's disown-opener. These seem largely similar so we should pick a common approach and figure out where to put it (a separate response header, FP, CSP, or something else)

Web-facing security benefits: In addition to allowing browser's to add process-based isolation for the window, this would protect applications from several classes of cross-origin information leaks: vulnerabilities based on counting window.frames, tabnabbing, and some variants of XS-Search and Silhouette attacks.

2. Protections at the resource level

Main goal: Protect authenticated responses from being exposed to processes owned by non-cooperating origins -- prevent evil.com from being to load the bytes of victim.com/sensitive into its address space where it can be exfiltrated via speculative execution.

Mechanisms: CORB (by default); CORP / Sec-Metadata / Same-site cookies (opt-in). These are largely complementary so there is benefit to implementing several/all of them.

Web-facing security benefits: Potential to protect against large classes of endemic web bugs (CSRF, XSSI, clickjacking, timing attacks), but the defensive properties and adoptability vary significantly depending on the proposal (covered to some extent in the Spilling the beans paper.)

3. Restrictions on windows which want to use mechanisms that can serve as high-resolution timers 

Main goal: Allow applications to use SharedArrayBuffer and WASM threads even in browsers which don't support full process-based isolation, without letting these applications execute reliable Spectre-like attacks on other origins. In other words, unblock SABs for the web.

Mechanisms: "COWP level 2"; also touched upon in the X-Bikeshed proposal.

Web-facing security benefits: This could potentially turn into a broader sandbox-like mode where web applications get access to more powerful features at the cost of conforming to certain restrictions (e.g. requiring all fetches to be in CORS mode).

*

With regards to:

 

My understanding is that browsers with process-based site isolation will still need to implement the resource-level protections from #2 (CORB by default, and Sec-Metadata/CORP as opt-in mechanisms to protect remaining resource types from leaking across origins). Browsers without full site isolation will need to additionally implement #1. Arguably, all browsers might want to consider gating SABs on the implementation of #3, but there's a little more nuance to this.

Because of the Web-facing security benefits you listed, which are independent of full site isolation, it seems like all browsers would want to implement #1.

I completely agree. I wasn't sufficiently precise above -- I'd meant to say that #1 is necessary to offer protection against speculative execution in the absence of SI; but there are certainly other good reasons for developers to use something like COWP in their applications (we certainly want to do this for several Google products and are counting on cross-browser support for the feature).

 

Also, for the record, in a previous thread, we were and are in favor of doing what you suggested and having all browsers gate SABs on (some variant of) #3.  Now that Chrome has unconditionally enabled SAB on desktop, though, it seems like that ship has sailed.

I'll leave it for someone on the Chrome team to comment on this because I'm not familiar with the details, but my hope is that due to the limited use of SABs this is something that could still be revisited (especially given that AFAIK this does pose a problem for non-CORB responses in Chrome).

[Chris Palmer]

I agree.

On Sat, Sep 29, 2018 at 2:18 PM Geoffrey Garen <gga...@apple.com> wrote:

Hi Artur,

With the clarification, supplied later in this thread, that even browsers that implement site isolation have reason to implement #1, I think this is an accurate summary.

Thanks,

Geoff

[Geoffrey Garen]

Hi Artur,

With the clarification, supplied later in this thread, that even browsers that implement site isolation have reason to implement #1, I think this is an accurate summary.

Thanks,

Geoff

On Sep 27, 2018, at 2:38 AM, 'Artur Janc' via isolation-policy <isolatio...@chromium.org> wrote: