5 ms·

This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton mi

by rtpg 9y ago

This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton misses, if you can't control what the victim process accesses, it seems harder to exploit. We're all talking about how Spectre is this magic "get access to any memory from any process". But it looks to me like it's a new class of attack, that still requires specific entry points for the software you're trying to attack. I'd like to be proven wrong on this, but it _feels_ like this is more of a software thing like other timing bugs. In theory you can write software that isn't vulnerable EDIT: my reading of the "JS Spectre implementation" is "JIT code runs in the process of the browser + you can write JS code to read the process's own memory". I can imagine messiness with extensions (1Password in particular).

stupidcar 9y ago
I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch. Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likely go. Then you trigger the victim process in the way you know will cause a very similar branching operation. Even though it's operating within an entirely different process, the branch predictor uses what it learnt in the hostile process to predict the branch result in the victim process. It jumps to the address the hostile process taught it, and starts to speculatively execute code there. Eventually, it figures out it guessed wrong, but by then it's too late, and the information has leaked via a side-channel in a way that the hostile process can detect. So, essentially, you're use the branch predictor's cache to send the memory address. And you're not sending it to the victim process, you're sending it directly to the CPU. The victim process will never even know it's been attacked, because when the branch predictor hides the consequences of its incorrect guess from being detected by conventional means.
- rtpg 9y ago
  this still seems off to me. I get that the victim process' branch prediction can be messed with. But if my victim process is: password = "password" secret = "magic BTC wallet secret key" while True: password_attempt = input() if constant_time_compare(password, password_attempt): print(secret) And my input is something like: result = "" while sys.stdin.peek() not in ['\n', EOF]: result += sys.stdin.get() Then at no point is the victim program really exposing any pointer logic, so not even the victim process will be accessing the `secret` during execution, let alone the hostile process. The examples given all include arrays provided by the hostile program, and some indexing into the arrays. I definitely see this being an issue in syscalls, but if that's the scope of this, I wouldn't call Spectre a "hardware bug" any more than other timing attacks would be hardware bugs.
  - stupidcar 9y ago
    The victim code doesn't need to have some explicit pointer arithmetic, it just has to have some sequence of bytes, somewhere in its address space (the "gadget"), that can be used to read a memory address based on a value stored in a register that can be affected by input supplied from the hostile process. The branch prediction is used to speculatively execute that code. The "Example Implementation on Windows" section in the Spectre paper goes into more detail about this.

by rtpg 9y ago

stupidcar 9y ago

I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch. Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likely go. Then you trigger the victim process in the way you know will cause a very similar branching operation. Even though it's operating within an entirely different process, the branch predictor uses what it learnt in the hostile process to predict the branch result in the victim process. It jumps to the address the hostile process taught it, and starts to speculatively execute code there. Eventually, it figures out it guessed wrong, but by then it's too late, and the information has leaked via a side-channel in a way that the hostile process can detect. So, essentially, you're use the branch predictor's cache to send the memory address. And you're not sending it to the victim process, you're sending it directly to the CPU. The victim process will never even know it's been attacked, because when the branch predictor hides the consequences of its incorrect guess from being detected by conventional means.

rtpg 9y ago
this still seems off to me. I get that the victim process' branch prediction can be messed with. But if my victim process is: password = "password" secret = "magic BTC wallet secret key" while True: password_attempt = input() if constant_time_compare(password, password_attempt): print(secret) And my input is something like: result = "" while sys.stdin.peek() not in ['\n', EOF]: result += sys.stdin.get() Then at no point is the victim program really exposing any pointer logic, so not even the victim process will be accessing the `secret` during execution, let alone the hostile process. The examples given all include arrays provided by the hostile program, and some indexing into the arrays. I definitely see this being an issue in syscalls, but if that's the scope of this, I wouldn't call Spectre a "hardware bug" any more than other timing attacks would be hardware bugs.
- stupidcar 9y ago
  The victim code doesn't need to have some explicit pointer arithmetic, it just has to have some sequence of bytes, somewhere in its address space (the "gadget"), that can be used to read a memory address based on a value stored in a register that can be affected by input supplied from the hostile process. The branch prediction is used to speculatively execute that code. The "Example Implementation on Windows" section in the Spectre paper goes into more detail about this.