9 ms·

Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Saf

by omcnoe 2y ago

Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling `window.open` in js. All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" process in the address space.

r00fus 2y ago
Do other browsers have process isolation for new tabs?
- tptacek 2y ago
  Not necessarily for tabs on the same web site, but for different sites, yes. Hence "site isolation".
  - lxgr 2y ago
    To be fair, this is (relatively, compared to the age of the web) new behavior though. Even Chrome, which pioneered the "tab per process" model, didn't isolate same browsing group context sites for a long time, and still shares processes on Android as a resource optimization: https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md#Full-Site-Isolation-site_per_process https://chromium.googlesource.com/chromium/src/+/main/docs/p... Firefox only released their "Project Fission" in 2021, i.e. three years after Spectre.
lxgr 2y ago
That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...
- wging 2y ago
  So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.
  - connicpu 2y ago
    It's not unreasonable to set a different header value for the login page only, where it should be safe because no external user data is being rendered.
  - lxgr 2y ago
    Sites can also opt into the same behavior by setting the rel="noopener" or alternatively target="_blank" attributes on outgoing links (i.e. <a> tags). And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
    - wging 2y ago
      That is a little different, though: those attributes are for if you're example.com linking to protonmail, the header is for if you're protonmail deciding on security policies for interactions with example.com.
      - lxgr 2y ago
        The header works in both directions; cf. the table on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr....
- omcnoe 2y ago
  Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a penalty can opt their sites into the "same process" flag if really needed.
kllrnohj 2y ago
The writing was on the wall for in-process sandboxing with Spectre, but that seems to have faded a bit. This just re-enforces that. Things like "safe in-process sandboxing with WASM" are just a fantasy, it can't be implemented.
- lxgr 2y ago
  Safe in-process sandboxing is obviously possible and even trivial. It does get harder if you care about performance, though.
  - saagarjha 2y ago
    If the costs are high enough you’re basically reimplementing multi-process isolation from first principles.
  - willtemperley 2y ago
    What I know as a developer is web security is really hard. Last week there was a DOM clobbering gadget deep in my TypeScript world and I really didn't have the energy to understand who wants to clobber my DOM and why they need a gadget. I want to build stuff and what worries me is this stuff is just simply not foreseeable.
    - lxgr 2y ago
      DOM security is a completely different beast from process isolation with WASM (in a web context or otherwise). The attack surface is vastly greater, due to the much larger API complexity.
  - kllrnohj 2y ago
    "trivial" how do you figure? Remember these exploits bypass your own code's conditionals over a shockingly far duration. Unless you just mean for incredibly restrictive usages such as eBPF? possible absent any performance concerns at all, yeah sure
    - 2y ago
H8crilA 2y ago
No, only some of the side channel magic doesn't matter if you live in a different virtual memory space. Other past attacks didn't use virtual memory pointers and used physical memory pointers or didn't use any pointers at all - one could read data from another process, the kernel, another VM, the SGX enclaves or even proprietary CPU manufacturer code that runs on the CPU, like the CPU signing keys used for remote attestation.
btown 2y ago
This, 100%. From the SLAP paper linked in the OP https://predictors.fail/files/SLAP.pdf https://predictors.fail/files/SLAP.pdf : > Considerations for Safari. We emphasize the importance of site isolation [55], a mechanism preventing webpages of different domains from sharing rendering processes. Site isolation is already present in Chrome and Firefox [42, 55], preventing sensitive information from other webpages from being allocated in the attacker’s address space. While its implementation is an ongoing effort by Apple [3, 4], site isolation is not currently on production releases of Safari. On the contrary, we also reflect on [Webkit's memory allocator] libpas’s heap layout from Section 6.3, allowing sites to not only share processes, but also heaps. Partitioning JavaScript heaps by at least several memory pages per-webpage would prevent JavaScript strings from the target webpage from being allocated within the 255-byte reach of the LAP.
cluckindan 2y ago
In Safari settings under Advanced, it’s possible to enable ”verify window.open user gesture”. Does that help at all?
- ddtaylor 2y ago
  AFAIK this only means the attacker has to dupe you into doing a UI event like scrolling or clicking or touching something on page. Very easy to do.
yard2010 2y ago
Safari is Internet Explorer of the 20'
- jabwd 2y ago
  This is a flawed comparison in many ways. As you might not understand IE was problematic because of its massive install base and everyone only, and only writing their websites for chrome oh wait. Typo'd there, meant IE.

by omcnoe 2y ago

r00fus 2y ago

Do other browsers have process isolation for new tabs?

tptacek 2y ago
Not necessarily for tabs on the same web site, but for different sites, yes. Hence "site isolation".
- lxgr 2y ago
  To be fair, this is (relatively, compared to the age of the web) new behavior though. Even Chrome, which pioneered the "tab per process" model, didn't isolate same browsing group context sites for a long time, and still shares processes on Android as a resource optimization: https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md#Full-Site-Isolation-site_per_process https://chromium.googlesource.com/chromium/src/+/main/docs/p... Firefox only released their "Project Fission" in 2021, i.e. three years after Spectre.

lxgr 2y ago

That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...

wging 2y ago
So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.
- connicpu 2y ago
  It's not unreasonable to set a different header value for the login page only, where it should be safe because no external user data is being rendered.
- lxgr 2y ago
  Sites can also opt into the same behavior by setting the rel="noopener" or alternatively target="_blank" attributes on outgoing links (i.e. <a> tags). And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
  - wging 2y ago
    That is a little different, though: those attributes are for if you're example.com linking to protonmail, the header is for if you're protonmail deciding on security policies for interactions with example.com.
    - lxgr 2y ago
      The header works in both directions; cf. the table on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr....
omcnoe 2y ago
Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a penalty can opt their sites into the "same process" flag if really needed.

kllrnohj 2y ago

The writing was on the wall for in-process sandboxing with Spectre, but that seems to have faded a bit. This just re-enforces that. Things like "safe in-process sandboxing with WASM" are just a fantasy, it can't be implemented.

lxgr 2y ago
Safe in-process sandboxing is obviously possible and even trivial. It does get harder if you care about performance, though.
- saagarjha 2y ago
  If the costs are high enough you’re basically reimplementing multi-process isolation from first principles.
- willtemperley 2y ago
  What I know as a developer is web security is really hard. Last week there was a DOM clobbering gadget deep in my TypeScript world and I really didn't have the energy to understand who wants to clobber my DOM and why they need a gadget. I want to build stuff and what worries me is this stuff is just simply not foreseeable.
  - lxgr 2y ago
    DOM security is a completely different beast from process isolation with WASM (in a web context or otherwise). The attack surface is vastly greater, due to the much larger API complexity.
- kllrnohj 2y ago
  "trivial" how do you figure? Remember these exploits bypass your own code's conditionals over a shockingly far duration. Unless you just mean for incredibly restrictive usages such as eBPF? possible absent any performance concerns at all, yeah sure
  - 2y ago

H8crilA 2y ago

No, only some of the side channel magic doesn't matter if you live in a different virtual memory space. Other past attacks didn't use virtual memory pointers and used physical memory pointers or didn't use any pointers at all - one could read data from another process, the kernel, another VM, the SGX enclaves or even proprietary CPU manufacturer code that runs on the CPU, like the CPU signing keys used for remote attestation.

btown 2y ago

This, 100%. From the SLAP paper linked in the OP https://predictors.fail/files/SLAP.pdf https://predictors.fail/files/SLAP.pdf : > Considerations for Safari. We emphasize the importance of site isolation [55], a mechanism preventing webpages of different domains from sharing rendering processes. Site isolation is already present in Chrome and Firefox [42, 55], preventing sensitive information from other webpages from being allocated in the attacker’s address space. While its implementation is an ongoing effort by Apple [3, 4], site isolation is not currently on production releases of Safari. On the contrary, we also reflect on [Webkit's memory allocator] libpas’s heap layout from Section 6.3, allowing sites to not only share processes, but also heaps. Partitioning JavaScript heaps by at least several memory pages per-webpage would prevent JavaScript strings from the target webpage from being allocated within the 255-byte reach of the LAP.

cluckindan 2y ago

In Safari settings under Advanced, it’s possible to enable ”verify window.open user gesture”. Does that help at all?

ddtaylor 2y ago
AFAIK this only means the attacker has to dupe you into doing a UI event like scrolling or clicking or touching something on page. Very easy to do.

yard2010 2y ago

Safari is Internet Explorer of the 20'

jabwd 2y ago
This is a flawed comparison in many ways. As you might not understand IE was problematic because of its massive install base and everyone only, and only writing their websites for chrome oh wait. Typo'd there, meant IE.