12 ms·

From the linked site: > In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate

From the linked site: > In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate from other sites. Wasn't the whole point of Spectre/Meltdown to read the virtual address space of a different process?

AshleysBrain 2y ago
As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. If browsers put different origins in the same process - which they used to - then JS code can break the same-origin security barrier and read details of other origins directly from memory. By putting each origin in its own OS address space they are protected from this attack as JS can still only read data from its own origin even when using security flaws to read any part of the address space.
- branko_d 2y ago
  > As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it. Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently): https://meltdownattack.com/ https://meltdownattack.com/ > While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
  - jcranmer 2y ago
    > Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? If you're making a VM such that the running code can only access a particular array, Spectre allows a timing attack that can get malicious code in the VM access to the full memory space. You're right that it's not that scary for most use cases. What it really means is that it's hopeless to make memory inaccessible to a sandbox without putting a process isolation barrier betwixt the two, as there's no real way to close out all of the timing attack possibilities. In principle, if the only thing you needed to foreclose was memory vulnerabilities, then sufficiently good programming™ would let you have the sandbox in the same process space; as a matter of practice, though, anyone looking at product security seriously would still make you put in process isolation, because that kind of good programming just doesn't exist at scale yet. (Note that Meltdown, but not Spectre, allows timing attacks that cross process isolation domains.)
joshkel 2y ago
As I understand it: Meltdown lets a process read from kernel memory. There are several variations of Spectre. The first variant ("Spectre V1") lets a process read its own memory; the second variant ("Spectre V2") lets a process read another process's memory. Web browser manufacturers seem to be focused on preventing Spectre V1, although I'm unclear on whether that's because V2 is too hard to exploit from JavaScript, is mitigated in other ways (e.g., CPU updates), etc. Further reading: https://stackoverflow.com/q/53042230/25507 https://stackoverflow.com/q/53042230/25507, https://stackoverflow.com/q/48200753/25507 https://stackoverflow.com/q/48200753/25507, https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html https://security.googleblog.com/2018/07/mitigating-spectre-w..., https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-..., https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

AshleysBrain 2y ago

As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. If browsers put different origins in the same process - which they used to - then JS code can break the same-origin security barrier and read details of other origins directly from memory. By putting each origin in its own OS address space they are protected from this attack as JS can still only read data from its own origin even when using security flaws to read any part of the address space.

branko_d 2y ago
> As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it. Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently): https://meltdownattack.com/ https://meltdownattack.com/ > While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
- jcranmer 2y ago
  > Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? If you're making a VM such that the running code can only access a particular array, Spectre allows a timing attack that can get malicious code in the VM access to the full memory space. You're right that it's not that scary for most use cases. What it really means is that it's hopeless to make memory inaccessible to a sandbox without putting a process isolation barrier betwixt the two, as there's no real way to close out all of the timing attack possibilities. In principle, if the only thing you needed to foreclose was memory vulnerabilities, then sufficiently good programming™ would let you have the sandbox in the same process space; as a matter of practice, though, anyone looking at product security seriously would still make you put in process isolation, because that kind of good programming just doesn't exist at scale yet. (Note that Meltdown, but not Spectre, allows timing attacks that cross process isolation domains.)

joshkel 2y ago

As I understand it: Meltdown lets a process read from kernel memory. There are several variations of Spectre. The first variant ("Spectre V1") lets a process read its own memory; the second variant ("Spectre V2") lets a process read another process's memory. Web browser manufacturers seem to be focused on preventing Spectre V1, although I'm unclear on whether that's because V2 is too hard to exploit from JavaScript, is mitigated in other ways (e.g., CPU updates), etc. Further reading: https://stackoverflow.com/q/53042230/25507 https://stackoverflow.com/q/53042230/25507, https://stackoverflow.com/q/48200753/25507 https://stackoverflow.com/q/48200753/25507, https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html https://security.googleblog.com/2018/07/mitigating-spectre-w..., https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-..., https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...