securityspectreside-channel-attacks

How Process can Share array2(the oracle array) in Spectre Attack?


In spectre paper, the PoC place Victim and Attacker code in same process.

The code is like this:

if (x < array1_size)
  y = array2[ array1[x] * 256 ];

So Attacker and victim can use the same array2(because they are in same code, process).

But in real world, Attacker and Victim is separated(they are different process), so they can't share array2.

So here is my question, in this case, How can Attacker measure access time to array2?
How can Attacker know array2's address?

I have no idea how to attacker access to array2. What is misunderstood here?


Solution

  • The code from the question refers to Spectre Variant 1, also known as bounds check bypass.

    What is misunderstood here?

    Instead of thinking of Variant 1 in terms of victim process and attacker process, think of it as sandboxed attacker code, whose goal is to read memory outside of its sandbox.

    In other words, the attacker controls some code which runs within a software sandbox, and this software sandbox would normally enforce that each code domain only accesses its own data. However, Spectre allows the attacker's code to bypass such sandbox's enforcements.

    For example, the attacker provides Javascript code for a malicious website which will be sandboxed by the Javascript interpreter upon execution. The Javascript interpreter would check that code such as y = array2[ array1[x] * 256 ] can only execute if x < array1_size. This is called bounds check and serves to ensure that the website is not allowed to read from the address space of the browser process running it. Upon execution, the attacker (who controls x) can perform conditional branch misprediction by having their own code train the branch predictor to take the branch if (x < array1_size). Finally, the attacker will set x to a desired, out-of-bounds value which, because of Spectre, will allow them to bypass the bounds check of the sandbox and read memory from the address space of the browser process. In summary, the attacker here controls the code of a (sandboxed) website and Spectre allows them to read memory of the browser where the website is opened (which would normally be prevented by the sandbox).

    The second example uses eBPF, where the attacker injects and executes some code from the Linux kernel. The eBPF interface allows unprivileged users to do so. This code would normally be executed in a in-kernel VM/sandbox which performs bounds checks to prevent the loaded code from reading arbitrary memory. However, Spectre allows an attacker violate this sandboxing outside of the BPF sandbox and leak arbitrary memory. In summary, the attacker here is an unprivileged user of the host and Spectre allows them to read arbitrary memory on the host!

    But in real world, Attacker and Victim is separated(they are different process)

    Not in this case. As explained above, in Spectre Variant 1 the "victim's code" encapsulates the "attacker's code" within the same process. The attacker's code would normally be isolated by the victim using a software sandbox, but Spectre allows to bypass that and read any memory in the victim's address space.