Skip to main content


Holy shit.. #Apple, can I get a refund?

Unpatchable vulnerability in Apple chip leaks secret encryption keys

https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/

Jonathan Lamothe reshared this.

in reply to stux⚡

"The vulnerability can be exploited when the targeted cryptographic operation and the malicious application with normal user system privileges run on the same CPU cluster."

Someone really dropped the ball on this one

in reply to stux⚡

to be fair, getting this stuff right is _really_ hard. It would have been naive of us to believe Apple was somehow flawless.
I’m sure we’ll see more security flaws to be fixed in the future as M-Series becomes a juicier target.
in reply to stux⚡

not to engage in schadenfreude too much but it is nice for once to hear a bit of bad news related to the M1 after all of the positivity its fans threw at us x86 troglodytes 😀 .
in reply to A B

@ab78702 If it was fixable perhaps :blobcatgiggle:

This one really hurts a load of people, who knows how many backdoors are out there already

I only want the most secure for every system, no matter of Linux, Win or mac

@A B
Unknown parent

stux⚡

@freemo Perhaps indeed

This one is quite serious, my mac isn't even that old and basically unsafe now

Unknown parent

stux⚡
@freemo I dont (yet) but it's about the garantuee 😉 If such a vul is fixable im "okay" with it but it seems we're stuck with a perm hole in the wall
in reply to stux⚡

Intel and AMD, welcome Apple to the speculative execution vulnerability club!

reshared this

in reply to stux⚡

Itoddlers lost.
This entry was edited (1 month ago)
in reply to stux⚡

But macs don't get viruses. Might be an excuse to lock down the mac like ios.
in reply to stux⚡

@ErikUden
The full article actually lists 3 different fixes.
Most straightforward for M1 & M2 is restricting processes that handle certain keys to the efficiency CPU’s that don’t have this cpu cache being exploited.
For the M3 a bit can be set for memory that has these keys so they can’t exist in the vulnerable cache.

This is a clickbait title being they actually disclose these fixes in the article… 😵‍💫

in reply to Bryan Whitehead

@Bryan Whitehead If I'm not mistaken, these "fixes" are workarounds that incur performance penalties, do they not?
in reply to Jonathan Lamothe

@me
M3 with bit fiddling is the arm designed “correct way” as far as I know.

I’m just a muppet compared to the true ARM masters like @marcan. There is a great 🧵 from him here about this vulnerability: https://social.treehouse.systems/@marcan/112135772533553951

in reply to Jonathan Lamothe

@me @Bryan No, this is by design. The chips have an optimization that is not secure to do for crypto code. Crypto code is supposed to set a bit to ask for these optimizations to be turned off. This is a standard ARM architecture mechanism that was released 7 years ago. It doesn't make any sense to turn off this optimization for everything since it only matters for crypto stuff, that's why this bit exists so the CPU knows when it's safe to do this optimization and when not.

This works as intended for M3. For M1 and M2 it does not, but I absolutely guarantee there's a workaround, because CPUs always have special bits to turn off features like this in general, just Apple forgot to hook it up to the "standard" bit prior to M3. It's up to Apple to develop a kernel-level workaround for M1/M2.

in reply to Hector Martin

It's probably just a kernel/firmware update away from being fixed.
in reply to Eragon

They could fix it in a kernel update by disabling the optimization globally (at a performance cost). To disable it only for crypto code they will have to create a new API and get developers to use it, since they will have to add new syscalls to twiddle the disable bit via the kernel.

It is *possible* that a trap mechanism exists that could hook this up to the standard bit (with kernel assistance) and avoid needing a new API, but we haven't observed the existence of such a mechanism yet.

This entry was edited (1 month ago)
in reply to Hector Martin

@Hector Martin @Bryan Whitehead Ah, so the so-called performance hit is due to the fact that it it can't use optimizations that it was never intended to in the first place, then?
in reply to Jonathan Lamothe

Correct. The performance hit will be practically zero for crypto code anyway, since it's not the kind of code these optimizations are intended to help. They're more for complex object-oriented code, pointer-based data structures, and stuff like that.
This entry was edited (1 month ago)
in reply to stux⚡

Maybe they'll handle it like they did the last fiasco. Deny it was a design failure and send everyone a rubber case for their MacBooks.
in reply to stux⚡

this is just…just dandy for the bad guys…thanks apple. 😠
in reply to stux⚡

and after that i really think that closing app to store only would fix many problems of macos the sideload of all OS must be limited to developers and people capable to handle it (maybe some sort of certification (free) to check you are able to maintain an security hygiene)
in reply to stux⚡

Forensic specialists are happy about that. 😁
in reply to stux⚡

LOL! I know! Sucks, doesn't it. Well, we're only human and nothing is ever perfect.
in reply to stux⚡

no refunds but you can stop buying Apple products. Then you don't have to worry about where they send your data.
in reply to stux⚡

That indeed is an interesting question, that I would like to have a legal answer to, you know, from a product liability and consumer rights perspective.

If something is broken, you have a right to get it fixed (at least in a limited way where I live). If it can't be fixed, you have a right for reverse transaction.

I wonder if this applies here. In my opinion it does, but #IANAL

in reply to stux⚡

why would you be eligible? You were the one trusting a black box

This website uses cookies. If you continue browsing this website, you agree to the usage of cookies.