Thanks for the response Samuel!
Totally agree that there are other ways of crafting gadgets.
We are currently working on getting the V8 sandbox up and running in our infrastructure.
I can also confirm that it prevents attackers from leveraging ArrayBuffer to get a 64-bit read primitive.
Moreover, we are also working on isolating secrets from processes running V8 isolates.
Not only from the Spectre point of view but also to reduce the leakage potential of a V8 zero day.
On the short term, we are looking for ways to make publicly known primitives harder to exploit respectively detect exploitation, and, therefore, look a bit into that direction as well.
-Martin
Hi!
Yeah from the V8 security PoV, we assume that an attacker can already read all memory in the process, and there is no effort to prevent that. In particular, the V8 sandbox also explicitly assumes this attacker model.
That said, the
V8 sandbox probably and mostly by accident already makes reading out-of-sandbox memory through something like Spectre a bit harder, e.g. ArrayBuffers can no longer be used for that purpose. So that might be something to look into: can the sandbox be extended to defend against speculative reads. I assume it will be hard though: what happens once you misspeculate a branch for example? Probably at that point all bets are off. Also it wouldn't affect any embedder code etc. This would also assume that you have one sandbox per tenant. And finally, I think it'd always be a "best-effort" thing: we wouldn't want to make preventing reads a goal of the sandbox, and so may also not want to take patches in that regard if they have other side effects.
Cheers!
Samuel