4 ms·

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 - whic

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.)

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.)