Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

51–60 of 365 posts

Re: New speculative attacks on Apple CPUs

#51
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:/…

Your links are all from 2021. I remember there was a lot of criticism at the time and so they updated their bug bounty program which quite a number of changes:

https://security.apple.com/blog/apple-security-bounty-upgrad...

Would be interesting to see if it made a difference.

Re: New speculative attacks on Apple CPUs

#52
post #44

Earlier quoted context omitted.

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.

If the costs are high enough you’re basically reimplementing multi-process isolation from first principles.

Re: New speculative attacks on Apple CPUs

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

In practice probably not, as long as general population keeps it enabled. I mean, looking at effort required, it's not worth spending time exploiting spectre these days, because virtually everyone is protected. If you're not likely to be directly targeted, "herd immunity" will work.

Re: New speculative attacks on Apple CPUs

#54
post #42
post #14

Earlier quoted context omitted.

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.

The language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration.

Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim.

But "the same flavor of vulerability" seems to be a mischaracterization.

Re: New speculative attacks on Apple CPUs

#55

Bizarre 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).

Indeed, my Apple Watch (series 3) has always been immune to all spectre type attacks, the CPU is too simple. It doesn’t do speculative execution at all.

Re: New speculative attacks on Apple CPUs

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

A browser-based attack, in theory, could have happened with Spectre/Meltdown as well. I seem to recall a PoC for Spectre in the browser, actually. I believe it's also a reason that microsecond precision in the browser was made a bit more opaque since that era.

Re: New speculative attacks on Apple CPUs

#57
post #44

Earlier quoted context omitted.

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.

What I know as a developer is web security is really hard. Last week there was a DOM clobbering gadget deep in my TypeScript world and I really didn't have the energy to understand who wants to clobber my DOM and why they need a gadget. I want to build stuff and what worries me is this stuff is just simply not foreseeable.

Re: New speculative attacks on Apple CPUs

#58
post #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 maj…

So should Protonmail (and any other site with similarly sensitive data) be setting that header, then? It’s probably hard to change the default. I bet some use cases (SSO popups?) depend on it.

Re: New speculative attacks on Apple CPUs

#59
post #54
post #42

Earlier quoted context omitted.

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.

The language seems to argue otherwise: SLAP "allows the adversary to jump the LAP to the target webpage's string and trick the CPU into operating on it" and FLOP "allows us to run a function with the wrong arguments". That's absolutely not mere data exfiltration. Now, maybe this is because of a trampoline based on pre-existing Safari bugs and not the CPU misfeature itself. Again, the details are slim. But "the same f…

No, they’re correct.

Re: New speculative attacks on Apple CPUs

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

> double-digit-%

In the early days there was a ~10% hit, but that's changed a lot since then.

Post reply on HN