Hi, 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 > On 26.01.2024, at 13:27, Samuel Groß <[email protected]> wrote: > > 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 > <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/sandbox/README.md> > 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 > > On Thu, Jan 25, 2024 at 7:01 PM Martin Schwarzl <[email protected] > <mailto:[email protected]>> wrote: >>> There's not really any fully supported mechanism for this at all at the >>> moment; there's some logic for alignment of HeapNumbers so that their >>> double values stay aligned, so you can look for "AllocationAlignment" in >>> the heap directory (and the HeapObject::RequiredAlignment method), but at >>> the moment this isn't used and I think is broken if you allocate from >>> optimised code. Also keep in mind that allocation has to be preserved when >>> the GC moves objects, not just during allocation. >> Thank you very much for the answer. >> I see that this is a more difficult problem than expected. >> >>> Is this for a multi-tenant Isolate or something like that? >> Yes exactly, we have that multi-tenant scenario and therefore I am currently >> enumerating >> some possibilities to make exploitation harder. >> >>> On 25.01.2024, at 18:30, Leszek Swirski <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> +Samuel <> >>> >>> <> >>> There's not really any fully supported mechanism for this at all at the >>> moment; there's some logic for alignment of HeapNumbers so that their >>> double values stay aligned, so you can look for "AllocationAlignment" in >>> the heap directory (and the HeapObject::RequiredAlignment method), but at >>> the moment this isn't used and I think is broken if you allocate from >>> optimised code. Also keep in mind that allocation has to be preserved when >>> the GC moves objects, not just during allocation. >>> >>> Note that our security model doesn't really try to be robust against >>> Spectre at all (we rely on site isolation in Chrome to provide >>> process-level memory safety), and especially not for Spectre attacks that >>> are limited to reading within the V8 sandbox (which is not considered >>> sensitive). Is this for a multi-tenant Isolate or something like that? >>> >>> - Leszek >>> >>> On Thu, Jan 25, 2024 at 3:50 PM 'Martin Schwarzl' via v8-dev >>> <[email protected] <mailto:[email protected]>> wrote: >>>> Thank you for the response! >>>> >>>> It's more a security consideration w.r.t Spectre attacks >>>> (https://github.com/google/security-research-pocs/blob/master/spectre.js/leaky.page/templates/spectre_worker.js#L135). >>>> >>>> Is there an alternative way of aligning it, maybe after object generation? >>>> It feels like I am maybe missing where in compilation process I could >>>> influence the alignment. >>>> >>>> On Wednesday, January 24, 2024 at 6:45:05 PM UTC+1 [email protected] >>>> <mailto:[email protected]> wrote: >>>>> Hi, >>>>> >>>>> No, the V8 heap allocation doesn't currently support custom alignment. >>>>> Are you seeing these be in different cache lines a lot? I could imagine >>>>> that being a problem for a lot of objects if it's a performance issue. >>>>> >>>>> - Leszek >>>>> >>>>> On Wed, Jan 24, 2024 at 6:22 PM 'Martin Schwarzl' via v8-dev >>>>> <[email protected] <>> wrote: >>>>>> Hi, >>>>>> >>>>>> I was wondering if there is a primitive to align the memory >>>>>> representation in torque >>>>>> similar to alignas in C++. >>>>>> >>>>>> To provide more context I'd like to align the JSArrayBuffers members >>>>>> raw_byte_length, raw_max_byte_length and backing_store to be in the same >>>>>> cache line. >>>>>> >>>>> >>>>>> -- >>>>>> -- >>>>>> v8-dev mailing list >>>>>> [email protected] <> >>>>>> http://groups.google.com/group/v8-dev >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "v8-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to [email protected] <>. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/v8-dev/82f8624c-9b77-49e2-a04d-0c92a1a60206n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/v8-dev/82f8624c-9b77-49e2-a04d-0c92a1a60206n%40googlegroups.com?utm_medium=email&utm_source=footer>. >>>> >>>> >>>> -- >>>> -- >>>> v8-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://groups.google.com/group/v8-dev >>>> --- >>>> You received this message because you are subscribed to the Google Groups >>>> "v8-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected] >>>> <mailto:[email protected]>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/v8-dev/7d8b060f-de7c-4c87-914f-37368fd0841dn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/v8-dev/7d8b060f-de7c-4c87-914f-37368fd0841dn%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> >>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "v8-dev" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/v8-dev/OLXPyZEsntk/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected] >>> <mailto:[email protected]>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/CAGRskv-Ucfk_iTD4O2_WHzVyzszL1AqKYFYWN44tUFcmK%3DsQdw%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/CAGRskv-Ucfk_iTD4O2_WHzVyzszL1AqKYFYWN44tUFcmK%3DsQdw%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/77151BAB-A180-4FD5-BDD1-35317C7B7FFE%40cloudflare.com.
