Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

31–40 of 365 posts

Re: New speculative attacks on Apple CPUs

#31
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…

Do other browsers have process isolation for new tabs?

Re: New speculative attacks on Apple CPUs

#32
post #8
post #5

Interesting 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.

The LVP vulnerability was reported in September, for what it's worth.

Re: New speculative attacks on Apple CPUs

#33
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?

It depends on your threat model. If you don't run any untrusted code on your hardware (including Javascript), you can safely disable the mitigations. If you do run untrusted code, keep them enabled.

Re: New speculative attacks on Apple CPUs

#34
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…

That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1].

By setting a different policy, sites can protect themselves against this.

I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...

Re: New speculative attacks on Apple CPUs

#35
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.

Re: New speculative attacks on Apple CPUs

#36
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…

They’re speculatively executing code. It’s not traditional code execution. (You can, of course, read the papers for full details.)

Re: New speculative attacks on Apple CPUs

#37
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?

If your machine is air gapped and/or not running random downloaded code, I think it is a possible reasonable option.

Re: New speculative attacks on Apple CPUs

#38
post #24
post #6

Earlier quoted context omitted.

Does Apple pay bug bounties?

They claim to, but they drag their feet, demand terms most researchers find so unacceptable as to be a bit immoral (the point of "responsible disclosure" isn't, in fact, to hold secrets from the public arbitrarily long), and often end up paying only a fraction of what was expected, if anything. https://pxlnv.com/linklog/apple-bug-bounty-troubles/ https://www.marketplace.org/shows/marketplace-tech/looking-f... https:/…

The vibe I got talking to people like Mark Dowd about this is that they're running something closer to an exploit bounty program, and it's pretty focused on patterns of vulnerabilities common to some pretty specific threat actors.

Re: New speculative attacks on Apple CPUs

#39
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?

What are you doing where you see anything remotely close to double-digit-% gains from disabling spectre mitigations?

Re: New speculative attacks on Apple CPUs

#40
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…

No, only some of the side channel magic doesn't matter if you live in a different virtual memory space. Other past attacks didn't use virtual memory pointers and used physical memory pointers or didn't use any pointers at all - one could read data from another process, the kernel, another VM, the SGX enclaves or even proprietary CPU manufacturer code that runs on the CPU, like the CPU signing keys used for remote attestation.
Post reply on HN