Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

41–50 of 365 posts

Re: New speculative attacks on Apple CPUs

#41
post #18

Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling `window.open` in js. All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" proces…

This, 100%. From the SLAP paper linked in the OP https://predictors.fail/files/SLAP.pdf :

> Considerations for Safari. We emphasize the importance of site isolation [55], a mechanism preventing webpages of different domains from sharing rendering processes. Site isolation is already present in Chrome and Firefox [42, 55], preventing sensitive information from other webpages from being allocated in the attacker’s address space. While its implementation is an ongoing effort by Apple [3, 4], site isolation is not currently on production releases of Safari. On the contrary, we also reflect on [Webkit's memory allocator] libpas’s heap layout from Section 6.3, allowing sites to not only share processes, but also heaps. Partitioning JavaScript heaps by at least several memory pages per-webpage would prevent JavaScript strings from the target webpage from being allocated within the 255-byte reach of the LAP.

Re: New speculative attacks on Apple CPUs

#42
post #14

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/

Hm... as I read it this is much worse. Spectre/Meltdown were data isolation vulnerabilities. You could exploit side channel (mostly timing) information to intuit state about memory across a protection boundary. Basically you can prime the CPU state to allow you to tell which of multiple code paths the kernel/hypervisor/whatever took, and then go from there to reading arbitrary data. Which is bad, obviously. Here, the…

It's not remote code execution, it's the same flavor of "out of bounds read through speculation" as previous vulnerabilities. It's terrifying because they have a working proof of concept from untrusted JS in Safari, but there have been speculative execution in browser JS engines before now also.

Re: New speculative attacks on Apple CPUs

#44
post #18

Their SLAP demo provides a great example of how defence-in-depth can make/break the viability of an exploit. That terrifying Safari demo is possible because Safari fails to isolate new windows in individual processes when calling `window.open` in js. All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" proces…

The writing was on the wall for in-process sandboxing with Spectre, but that seems to have faded a bit. This just re-enforces that. Things like "safe in-process sandboxing with WASM" are just a fantasy, it can't be implemented.

Safe in-process sandboxing is obviously possible and even trivial. It does get harder if you care about performance, though.

Re: New speculative attacks on Apple CPUs

#46
post #13

Earlier quoted context omitted.

I wonder if Apple are being slow due to the complexity of the potential fix, or because they're dragging their feet.

Or it's a hardware issue and they don't have any way to do a microcode fix for this

It's could be unfixable without a significant performance penalty, but at minimum they could make safari do proper process isolation like every other browser does.

Re: New speculative attacks on Apple CPUs

#47
post #13
post #8

Earlier quoted context omitted.

> We disclosed our results to Apple on May 24, 2024. Apple’s Product Security Team have acknowledged our report and proof-of-concept code, requesting an extended embargo beyond the 90-day window. At the time of writing, Apple did not share any schedule regarding mitigation plans concerning the results presented in this paper. The vulnerability is over half a year old and over a quarter over the embargo window.

I wonder if Apple are being slow due to the complexity of the potential fix, or because they're dragging their feet.

Because the fix will most likely kill performance, like Spectre/Meltdown did, and then their pretty graphs wont look so impressive any more.

Re: New speculative attacks on Apple CPUs

#48
post #23

For any yung'uns seeing this for the first time, the spectre and meltdown attacks (and accompanying papers) are worth reading. https://spectreattack.com/

Is it bad that I disable spectre mitigations on all my PCs to get a free double-digit-% performance boost?

You're not getting a boost, you're avoiding a penalty. In some (but not all) cases you can avoid the penalty and the exploits by disabling SMT. Remember, SMT isn't twice as many cores, just twice as many half-cores. You'll be fine.

Re: New speculative attacks on Apple CPUs

#49
> On the other hand, although Chrome is equipped with Site Isolation, we demonstrate that it is not a perfect mitigation. We show the real-world existence of corner cases, where two subdomains of the same site can be merged into one process, again leading to LAP- and LVP-based attacks.

Did anyone spot where this is mentioned?

Edit: it doesn’t seem like they have a general attack. Rather, it’s that some sites are not in the public suffix list.

Edit 2: It’s also interesting that they found that iPhone 13 and iPhone 13 mini (which have the same processor and came out at the same time) differ in LAP in that they observed only the latter as having it. Very curious…

Post reply on HN