Live data from Hacker News

New vuln in Apple M-series allowing secret keys extraction can't be patched

twitter.com

21–30 of 145 posts

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#21
post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

For cryptographic applications yes. That is why people have spent significant effort to implement constant time algorithms to replace standard math and bitwise operations.

At the hardware level any optimizations that change performance characteristics locally (how long the crypto operation directly takes) or non locally (in this case the secrets leak via observation of cache timings in the attacker's untrusted code) are unsafe.

Intel DMPs already have a flag to turn off the same behavior that was exploited on the M1/M2. Which may suggest that the risk of this type of optimization was understood previously.

Mixing crypto operations with general purpose computation and memory accesses is a fragile balance. Where possible try utilizing HSMs, yubikeys, secure enclaves - any specialized hardware that has been hardened to protect key material.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#22
post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

It is bad, it is required for performance reasons.

The questions is what could be the solution going forward, which is going to be a huge change anyway. I do not see a way out of this with our current architectures.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#23
post #16

if this is confirmed I'm really interested into how exactly Apple will somehow deflect this and make it vanish like they somehow always manage to do with the myriad of issues they're facing over and over

It’s a total non issue for the majority of folks. It requires local access and takes hours under very specific conditions that don’t apply to most people. How often do you run a server that will run arbitrary crypto operations on attacker controlled inputs? Plus all the secrets in the Secure Enclave are immune to this attack, so your FileVault keys and your Apple Pay cards and all that jazz are completely safe. It su…

> It’s a total non issue for the majority of folks

People said the _exact_ same thing about Spectre/Meltdown. Then the JS PoCs came out

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#24
post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

My personal opinion is that we should solve it the opposite way - don't run untrusted code in the first place (with rare exceptions like dedicating an entire cpu core and a region of memory to a virtual machine, etc). Speculation is one of many side channel attacks, who knows what kind of crazy RF-based exploits are out there. AFAIK we still haven't fully solved rowhammer.

I think for "normal" users the main risk is JavaScript, which can (kind of) be mitigated in software without affecting the rest of the system, so no one really cares about these attacks. But the fundamental abstraction leak between physics and programming will always be there.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#25
post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

Should we make a petition for apple to make lockdown-like mode that disables speculative execution? I'll sign up for that.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#26
post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

Absolutely critical for performance, though. If there's a way out of this it might have to be better virtualization.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#27
Google, in 2021 [0]:

> While the PoC demonstrates the JavaScript Spectre attack against Chrome 88's V8 JavaScript engine on an Intel Core i7-6500U 'Skylake' CPU on Linux, Google notes it can easily be tweaked for other CPUs... It was even successful on Apple's M1 Arm CPU...

And Augury [1] in 2022 also affected Apple's A14 and M1 chips.

So have Apple been attempting to mitigate and failing, or ignoring the issue?

Surely chip manufactures can't keep ignoring these fundamental flaws

[0] https://security.googleblog.com/2021/03/a-spectre-proof-of-c...

[1] https://www.prefetchers.info/

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#28
post #14

> The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?

My personal opinion is that we should solve it the opposite way - don't run untrusted code in the first place (with rare exceptions like dedicating an entire cpu core and a region of memory to a virtual machine, etc). Speculation is one of many side channel attacks, who knows what kind of crazy RF-based exploits are out there. AFAIK we still haven't fully solved rowhammer. I think for "normal" users the main risk is…

So you browse the Internet with JavaScript turned off? You're a bigger person than I am ;).

The risk here is that there are more individuals with the skills to take this type of attack and bring it to a browser near you.

One apps data is another apps code.

Re: New vuln in Apple M-series allowing secret keys extraction can't be patched

#29
The title to article ..."secret keys"... had me thinking that this vuln might be a path to extracting the private keys from the secure enclave.

I'm not sure, but after a bit more reading, it sounds like private-keys or symmetric-keys can be extracted from other user-space or possibly kernel-space code execution. And NOT from the secure enclave.

Just for what it's worth.

Post reply on HN