OK, fun. What can we do to mitigate this until it gets patched?
New speculative attacks on Apple CPUs
11–20 of 365 posts
Re: New speculative attacks on Apple CPUs
#12Interesting that the researchers have gone public before a mitigation is in place from Apple. Seems in pretty stark contrast to the industry-wide coordination that went into patching and mitigating spectre.
> We disclosed SLAP to Apple on May 24, 2024, and FLOP on September 3, 2024
Re: New speculative attacks on Apple CPUs
#13Interesting that the researchers have gone public before a mitigation is in place from Apple. Seems in pretty stark contrast to the industry-wide coordination that went into patching and mitigating spectre.
> 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.
Re: New speculative attacks on Apple CPUs
#14For 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, they claim to have a remote exploit vulnerability. It's not that Apple is leaking data, it's that the CPUs have a bug where they appear to be actually executing code based on incorrectly-loaded ("predicted") data.
Though the details are, as is usually the case, thin. I await further analysis.
Re: New speculative attacks on Apple CPUs
#15Re: New speculative attacks on Apple CPUs
#16Aside: I feel like RUB has become kind of a global center for this kind of high-end offensive security work. Was I just not paying enough attention 10 years ago or is this a new-ish thing?
What is RUB?
Re: New speculative attacks on Apple CPUs
#17Re: New speculative attacks on Apple CPUs
#18Their 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" process in the address space.
Re: New speculative attacks on Apple CPUs
#19Bizarre the M1 is immune to both; I'm more secure by not upgrading. (Sure, there's still a few, but they are mostly minor by comparison, or newer chips are also affected.)
Newer CPUs use more and more "hacks" - out of order execution, caching, speculative execution, branch prediction, etc - to gain performance improvements. The further back you go, the less vulnerable CPUs generally are to these (but possibly more vulnerable to other kinds of attacks).
Re: New speculative attacks on Apple CPUs
#20Earlier 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.
Or it's a hardware issue and they don't have any way to do a microcode fix for this