Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

91–100 of 145 posts

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

#91

Post by madsbuch »

threeseed wrote: post #73
madsbuch wrote: post #9

Earlier quoted context omitted.

Using multiple devices: Credit cards for payment, instead og apple pay. A camera for taking pictures, instead of a camera app, a notebook to write notes, instead of an app. From my perspective the original comment is not rocket science?

What an awful and counterproductive experience. If you require someone to enter their credit card number every time they make a purchase they end up doing dumb, insecure things like storing it as a text file on their desktop. And having external hardware just means more cables, batteries, updates to keep it secure etc. Initiatives like PassKey, ApplePay, TouchID etc. have been a huge win for security and privacy.

Hey, this is completely up to you. nobody is trying to steal your apple pay.

this is merely the parent commenter's belief that they would should use different apps to reduce the risk vector when secrets are stolen.

no reason to completely ballistic.

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

#92

Post by not_the_fda »

eek2121 wrote: post #84
JediPig wrote: post #81

Earlier quoted context omitted.

the author(s) of the article, completely ignore the cpu itself can be patched. there is microcode underneath the ARM instructions for such scenarios. Look at intel, there has been undocumented microcode for decades I beleive these articles are just hype for street cred.

From what I have read, the microcode on M-series chips is NOT updatable. If this is the case, tsk tsk Apple.

I thought microcode was an artifact of CISC architectures, while the Arm is a RISC architecture.

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

#93

Post by madsbuch »

electric_mayhem wrote: post #11
madsbuch wrote: post #9

Earlier quoted context omitted.

Using multiple devices: Credit cards for payment, instead og apple pay. A camera for taking pictures, instead of a camera app, a notebook to write notes, instead of an app. From my perspective the original comment is not rocket science?

I learned from another commenter on HN when a post asks low-effort questions where the answer is common sense or implicitly understood, it’s most likely a bot or troll or shill. Best not to engage with them.

that makes sense. within the past couple of months the value of comments, especially before community cueation, has gone very much down.

Maybe hackernews is mostly LLMs speaking at this point.

what a shame.

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

#94

Post by hmottestad »

bluetomcat wrote: post #8

Now looking for an affordable M3 Max MBP that should cost less than my car :-)

“We also tested DMP activation patterns on other Apple processors and found that m2 and m3 CPUs also exhibit similar exploitable DMP behavior.”

Found this on the exploit site.

But it also says: "We observe that the DIT bit set on m3 CPUs effectively disables the DMP. This is not the case for the m1 and m2."

So if libraries set the DIT bit then M3 should be safe.

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

#95

Post by Dalewyn »

switch007 wrote: post #23
Kluggy wrote: post #16

Earlier quoted context omitted.

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

The SpectreMeltdown mitigations have caused me more grief than the problem themselves to this day.

These vulnerabilities definitely exist, that much is a matter of fact. But whether it's something someone should consider in their threat model is a different matter.

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

#97

Post by frankjr »

pjc50 wrote: post #50
bhawks wrote: post #21

Earlier quoted context omitted.

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)…

It's infuriating that all modern computers have a secure crypto TPM, but you're explicitly not allowed to use it for your own important keys, it's only for securing things against you like the DRM in certain drivers.

Is that not what e.g. this project allows you to do?

https://github.com/tpm2-software/tpm2-pkcs11

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

#98

Post by breckenedge »

resource_waste wrote: post #90

Wow, didn't this happen with Intel? I think that was a noticeable drop in performance. This is probably worse given people were trying to experiment with local LLMs on CPU. Its not like they even offer Nvidia.

Macs have GPUs and their architecture means that GPU has access to the full system RAM. Cuda isn’t a requirement for running ML workloads on a GPU.

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

#99

Post by [deleted] »

midtake wrote: 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?

[deleted]
Post reply on HN