3 ms·
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" secr
by 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 agoThe 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.