6 ms·

> The problem is, processes share code all the time, via shared libs, which makes Spectre attacks able to cross process boundaries. I don't think that is how i

> The problem is, processes share code all the time, via shared libs, which makes Spectre attacks able to cross process boundaries. I don't think that is how it works. Just because multiple processes map the same code (read-only) doesn't mean that they also have mappings to each others' data. If two processes shared mappings to the same data (e.g. after a fork() with no exec()) then what you say may be true. Just because I can write a program that uses libc doesn't mean that I can use that as a means to extract ssh keys from an ssh-agent that also is using libc.

bitwize 9y ago
Actually, it does. By warming up the branch-target buffer to call a particular function (called a "gadget") inside libc as the attacker, you can induce the victim process to speculatively execute that function, and thereby leak data. It's a bit more complicated and involved than Meltdown, or Spectre within the same process, but it is possible and depending on the gadget chosen, any data within the victim process could be recovered.
- mgerdts 9y ago
  I think you are now confirming what I was saying. The attacker uses a gadget in libc (or any other code) to cause side effects that are effective for reading memory within the process's address space. Since each process has its own address space, this does not allow process A to read memory from process B's address space. For this to happen, process A (the attacker) would need to interact with process B to cause the speculation to happen within process B. Or, as stated in the spectre paper: > Drawing from return- oriented programming (ROP) [33], in this method the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively. Speculation performed within process A (my web browser) doesn't give you access to the data within process B (ssh-agent). Maybe I misunderstood the intent of your sentence that I initially quoted. [edit to fix formatting]
  - bitwize 9y ago
    Process A uses repeated calls to the gadget to trick the CPU into thinking "hey, that's a frequently jumped to place, I'd better remember that for speculative execution." Then when Process B runs, when it comes up on a branch instruction, it calls the gadget speculatively, bringing with it information about process B across the call. This may require some interaction with Process B, but it's minimal (opening a socket that Process B is listening on might be enough). Whatever computation resulted from the speculative call is discarded BUT its effect on the cache is NOT. Process A can thus use timing information to determine what's in the cache and thus, exfiltrate data from process B. So no, you can't read memory across process boundaries directly. The CPU's virtual memory mechanism provides at least that much. The significance of Meltdown and Spectre is, that isn't enough. Using speculative execution, cache trickery, and timing-based attacks, information CAN be exfiltrated from a process even with virtual memory protection in place. If this gets you paranoid about your ssh-agent leaking data, good. One (relatively) easy way to mitigate this is to use the retpoline compilation technique, which replaces function calls with a RET to the function location. Because the target of a RET, being on the stack, is unknown up until the moment it happens, current CPUs do not speculate across a RET. (Though were it not for Meltdown and Spectre, maybe future CPUs might have made some guesses?) So Process B could not be induced to speculatively call the gadget if it were compiled with retpoline.

bitwize 9y ago

Actually, it does. By warming up the branch-target buffer to call a particular function (called a "gadget") inside libc as the attacker, you can induce the victim process to speculatively execute that function, and thereby leak data. It's a bit more complicated and involved than Meltdown, or Spectre within the same process, but it is possible and depending on the gadget chosen, any data within the victim process could be recovered.

mgerdts 9y ago
I think you are now confirming what I was saying. The attacker uses a gadget in libc (or any other code) to cause side effects that are effective for reading memory within the process's address space. Since each process has its own address space, this does not allow process A to read memory from process B's address space. For this to happen, process A (the attacker) would need to interact with process B to cause the speculation to happen within process B. Or, as stated in the spectre paper: > Drawing from return- oriented programming (ROP) [33], in this method the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively. Speculation performed within process A (my web browser) doesn't give you access to the data within process B (ssh-agent). Maybe I misunderstood the intent of your sentence that I initially quoted. [edit to fix formatting]
- bitwize 9y ago
  Process A uses repeated calls to the gadget to trick the CPU into thinking "hey, that's a frequently jumped to place, I'd better remember that for speculative execution." Then when Process B runs, when it comes up on a branch instruction, it calls the gadget speculatively, bringing with it information about process B across the call. This may require some interaction with Process B, but it's minimal (opening a socket that Process B is listening on might be enough). Whatever computation resulted from the speculative call is discarded BUT its effect on the cache is NOT. Process A can thus use timing information to determine what's in the cache and thus, exfiltrate data from process B. So no, you can't read memory across process boundaries directly. The CPU's virtual memory mechanism provides at least that much. The significance of Meltdown and Spectre is, that isn't enough. Using speculative execution, cache trickery, and timing-based attacks, information CAN be exfiltrated from a process even with virtual memory protection in place. If this gets you paranoid about your ssh-agent leaking data, good. One (relatively) easy way to mitigate this is to use the retpoline compilation technique, which replaces function calls with a RET to the function location. Because the target of a RET, being on the stack, is unknown up until the moment it happens, current CPUs do not speculate across a RET. (Though were it not for Meltdown and Spectre, maybe future CPUs might have made some guesses?) So Process B could not be induced to speculatively call the gadget if it were compiled with retpoline.