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

https://twitter.com/kimzetter/status/1770869722760061195

199 135 2 years ago

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

dalke8• 2 years ago

It definitely supports my belief that centralizing identity, payment, and apps into a single device is a fundamentally flawed security model.

aargh_aargh• 2 years ago

Can you elaborate what you mean?

I may be misunderstanding what you intended but how do you use traditional means of payment (credit card) without an identity? How do you check your email without identity?

EtienneK• 2 years ago

As opposed to what else?

Please elaborate.

Kluggy• 2 years ago

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 sucks that it exists, and crypto libraries that run on the platform outside of the Secure Enclave will get slightly slower, but no one will notice.

switch0072• 2 years ago

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

nextlevelwizard• 2 years ago

It requires local access

What does this mean? All I read is access to user space. Wouldn’t any web browser be enough?

Angostura• 2 years ago

I imagine something like a software framework that can be called if properly secure crypto is needed at the expense of performance

junon• 2 years ago

Like a TPM?

tombot• 2 years ago

Actual article https://arstechnica.com/security/2024/03/hackers-can-extract...

SuchAnonMuchWow• 2 years ago

actual source of the article: https://gofetch.fail/

shp0ngle• 2 years ago

The Ars article is arguably more useful than the vuln website, with more added context; it's not just blogspam.

bluetomcat• 2 years ago

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

eru6• 2 years ago

Here in Singapore, everything that Apple does costs less than any car you could buy.

sofixa2• 2 years ago

I know you're exaggerating because car prices in Singapore are very high (with good reason and kudos to the Singapore government for handling this well), but it's not true:

There are a bunch of second hand cars below 6000 Singapore Dollars on this website[1], which is the price of the 64GB/1TB Mac Studio[2].

1 - https://www.sgcarmart.com/used_cars/listing.php?MOD=&PRC=18&...

2 - https://www.apple.com/sg/shop/buy-mac/mac-studio

hmottestad• 2 years ago

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

Mortiffer• 2 years ago

some people's real world take https://www.reddit.com/r/MacOS/comments/1bkd3m4/unpatchable_...

nijaru• 2 years ago

Discussed here: https://news.ycombinator.com/item?id=39779195

midtake• 2 years ago

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?

SV_BubbleTime• 2 years ago

Isn’t the issue more akin to use after free? If the instructions and memory were wiped on prediction path failure wouldn’t that help?

black_puppydog• 2 years ago

nope. the side effects (which can be access times in case of non-failure, or voltage changes, or or or...) would still happen

bhawks4• 2 years ago

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.

amelius3• 2 years ago

For cryptographic applications yes.

Why only cryptographic applications? What if I'm writing a very sensitive e-mail, for instance?

legutierr2• 2 years ago

Where possible try utilizing HSMs, yubikeys, secure enclaves - any specialized hardware that has been hardened to protect key material.

Are there any circumstances where this hardware is accessible in the browser? As I understand, it is not generally available (if at all) for any cryptography you might want to do in the browser.

pjc502• 2 years ago

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.

usrusr2• 2 years ago

Is the untrusted code observer able to see cache timing implications of fetches to addresses that the MMU considers off limits for the process? This is what keeps surprising more, it does not align well with what I think I know about processors (not much)

datadeft• 2 years ago

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.

crest2• 2 years ago

Neither block ciphers, nor stream ciphers, nor common public key algorithms (RSA, Ed25519) need or even profit from this. They just need fast access to the register-register math, maybe loop sequentially through all members of a fixed sized array a fixed number of times. The only thing those implementing such algorithms would probably like having is a few kiB of safe to access scratchpad memory for code and data. On entry to the crypto code copy the code and data there, enable a constant time mode for compute instructions and run the algorithm at full speed without worrying.

PhilipRoman3• 2 years ago

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.

bhawks4• 2 years ago

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.

mort966• 2 years ago

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

pmontra4• 2 years ago

So, CPUs or cores (and maybe RAM) dedicated to run only trusted and only untrusted code?

Examples (I'm running Debian)

The kernel, the X11 server, terminal, ssh, bash, anything coming from the official Debian repos including the password manager: in the trusted environment.

browsers, electron apps, anything installed from unofficial repos or language and package managers (npm, rvm, asdf, etc): in the untrusted environment.

It reminds me of mainframes and their redundant and compartmentalized hardware architecture.

aaomidi• 2 years ago

The entire point of this chip is to keep secrets hidden from local processes.

JediPig• 2 years ago

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.

actualwitch• 2 years ago

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

bawolff3• 2 years ago

From the gofetch website, apple has already done this for m3 chips.

pjc502• 2 years ago

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

amelius3• 2 years ago

Perhaps we should do the crypto in constant time, and run all other applications using homomorphic encryption?

tsimionescu5• 2 years ago

FHE is unusably slow even for the simplest operations, and there is no reason to be sure it will ever be fast enough for any normal computing.

layer82• 2 years ago

Disabling all hardware optimizations becomes an option long before homomorphic encryption becomes an option, performance-wise.

mort966• 2 years ago

This isn't speculative execution.

EDIT: The downvotes make no sense. What this bug has in common with Spectre is that it has to do with cache timing. But in Spectre, the cache is affected by speculative execution; with "GoFetch", it's the pre-fetcher pre-fetching things which look like memory addresses. Pre-fetching is not speculative execution.

bawolff3• 2 years ago

Unless the comment was edited, the person you are responded to did not use the phrase "speculative execution"

crest2• 2 years ago

Speculation is required to get even close to the single-thread throughput expected of any modern CPU for anything worth running on a general purpose CPU. The problem is that there is no formal specified model to reason over side-channels not even just for timing side-channels. Most ISAs doesn't specify the time it takes execute instructions.

Lets assume I multiply two 64bit numbers. The CPU could just do it the same way every time and the worst-case has 4 cycles latency. It may also track if one of the factors is zero and dynamically replace the multiplication with a zeroing idiom that "executes" in 0 cycles when the scheduler learns that that either input is zero as an extreme example.

Less radical it could track if the upper halves of registers are zero to fast-path smaller multiplications (e.g. 32bit x 32bit -> 64bit) and shave off a cycle. IIRC some PowerPC chips did that, but for the second argument only. The ISA allowed it.

A realistic example are CPUs with data-dependent latency shift/rotate instructions. What do you do if an ISA doesn't specify if shift/rotate is constant time, but every implementation of it so far did it in constant time? Do you slowly emulate it out of paranoia that a future implementation may have variable latency? An other real-world example of this would be FPUs that have higher latency for denormalised numbers its just not relevant to (most) cryptographic algorithms.

How the fuck are you supposed to build anything secure, useful, and fast enough from that?

switch0072• 2 years ago

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/

acdha7• 2 years ago

Some of the authors of this paper worked on Augury, too, but note that this is a different angle than Spectre: that was speculative execution (running instructions before knowing which way a branch would evaluate) and this is data prefetching.

The reason this keeps coming up is that it isn’t a single issue but a class of attacks exploiting performance features, and attackers are getting more sophisticated as smart people figure out new techniques. Chip designers have been adjusting but are trying not to throw out the last couple decades of performance improvements, too.

camkego• 2 years ago

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.

StewardMcOy• 2 years ago

Correct. It's still very bad, but does not affect the secure enclave.

okokwhatever• 2 years ago

As usual nobody cares about the "Average users". This is a flaw, this is a very high risk issue for everyone and should be threaded as a big problem by Apple but as the "average user" is not important anymore...

acdha7• 2 years ago

The average user is compromised by social engineering, password reuse, or not installing updates. If you’re trying to improve matters for them, put your energy into getting them to adopt passkeys and patching promptly, and asking regulators for stricter penalties for phone number spoofing and delivering spam calls. I would wager that there are more people compromised every minute that way than will ever be compromised by this bug.

igtztorrero• 2 years ago

I'm sure Apple will provide a patch in the next few days. Mr Tim Cook will take care of the share price.

boesboes2• 2 years ago

Another day, another speculative execution vuln.. IMHO: all this speculation is a local maximum and it show we have fundamental issue with how we design 'computers'

layer82• 2 years ago

It's security vs. speed. Can't have both. It's a bit like security vs. convenience.

TeMPOraL• 2 years ago

Or security vs. usefulness.

boesboes2• 2 years ago

yeah, my thinking is we are to focussed on the current state-of-the-art approaches (i.e ooo superscalar, ht, memory architecture etc) where we can eek out the last few % of performance. I wonder if doing something radically different, would have a different tradeoff for performance vs security/trust.

yencabulator• 2 years ago

Speculation is just a kludge trying to speed up a legacy architecture. It is possible to obtain speed even without speculation, just not without some other fresh ideas.

For example the vaporware Mill architecture is in-order on the CPU level but compilers can optimize to run code very concurrently.

xpuente3• 2 years ago

Security through obscurity is really a bad idea, and Apple is no exception. In the long run, this will likely drive the adoption of RiscV as a better alternative.

colejohnson66• 2 years ago

This RISC-V evangelism is worrying. Using RISC-V doesn't make your system secure; Good ISA implementations do. The ISA has no bearing on security vulnerabilities. Perhaps a faulty decoder could be a vulnerability vector, but a faulty RISC-V decoder wouldn't be compliant, and neither would a faulty ARM decoder.

If I add a custom crypto extension to a RISC-V core and implement it badly, is that the fault of RISC-V? No! It's my own. And RISC-V doesn't help anyone here because their license allows me to keep my extension completely closed source - no different than Apple is today with ARM.

xpuente3• 2 years ago

My comment was not about the ISA implementation or specification, It's about the TCB (trusted compute base), which in Apple (like intel and AMD) is closed. In RiscV is open. I would recommend you to educate yourself on any topic before lecture others.

snvzz• 2 years ago

The ISA has no bearing on security vulnerabilities.

Complexity leads to bugs, some of which are going to be security bugs.

ISAs impose complexity upon implementations. To claim they do not matter would be disingenuous.

tzs2• 2 years ago

What does this have to do with security through obscurity? This is an issue with cache prefetching.

xpuente3• 2 years ago

It has to with the secure processor. Although you seems to ignore what is the TCB.

meindnoch• 2 years ago

Yes. This is good for Bitcoin.

resource_waste• 2 years ago

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.

breckenedge• 2 years ago

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.

planb• 2 years ago

Unfortunately, I don't think the real world applications of this exploit are explained anywhere. From skimming the paper , it looks like the attacker needs to be able to a) run code on the victim's machine and b) trigger the encryption process ("For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform private key operations.")

So for a) it might be sufficient to run javascript and for b) of course there are ways to inject data into server processes, processing data submitted by clients is what servers are for.

But a happens on clients (web browsers) and b would be a way to extract encryption keys from servers. But in what case can an attacker run code on a machine where they can also trigger the encryption (constantly for an hour like in the demonstration)? The only thing that comes to my mind would be a server side code-execution-sandbox that runs SSL termination on the same machine.

edit: Maybe stealing client certificate keys?

amckenna2• 2 years ago

Kim Zetter has a great post walking through some details and commentary across a few sources, related to the vulnerability - https://www.zetter-zeroday.com/apple-chips/

The cryptographic key itself isn’t placed in cache. But bits of material derived from the key gets placed in the cache, and an attacker can piece these bits together in a way that allows them to reconstruct the key, after causing the processor to do this multiple times. The researchers were able to derive the key for four different cryptographic algorithms: Go, OpenSSL, CRYSTALS-Kyber and CRYSTALS-Dilithium.
[Green] notes that in theory this attack might be used to break the TLS cryptography that a computer’s browser uses to encrypt communication between their computer and web sites, which could allow attackers to decrypt that communication to extract a user’s session cookie for their Gmail or other web-based email account and use it to log into the account as them.

AnthonyMouse2• 2 years ago

Suppose you have a MITM attacker, e.g. hotel WiFi. You have any page not using TLS open in a background tab, which the attacker uses to inject javascript. Meanwhile there is a different page open via TLS which you're actively using, so your browser is constantly using the session key to encrypt the traffic. The attacker is now recording the encrypted session and after an hour they crack the session key and can use it to go back and decrypt the traffic.

dmitrygr• 2 years ago

Clickbait. How can someone lacking the real docs for the CPU claim that this “can’t be patched”? How could they possibly know what chicken bits exist to disable what features?

Glant• 2 years ago

The page for the vuln states there is a bit you can flip to disable the entire feature on the M3, but states no such feature exists on the M1 and 2. If Apple hasn't told them about a similar bit on M1 and 2 in the 100 days since it was reported, there's a pretty good chance it doesn't exist.

amckenna2• 2 years ago

"After this story published, Apple told [Kim Zetter] they just posted the instruction about the DIT to their web site yesterday [MAR 21], timed to the public release of the researchers' findings, which means that developers were not told to do this fix prior to yesterday's release" [1]

The mitigation for the issue was posted in coordination with the publishing of the vulnerability. Given that the mitigation only applies to the M3 processor, it's reasonable to assume that there is no currently known mitigation for the M1 and M2 processors.

[1] https://www.zetter-zeroday.com/apple-chips/

ChrisArchitect• 2 years ago

[dupe]

Discussion on the actual vulnerability post: https://news.ycombinator.com/item?id=39779195

ryandvm• 2 years ago

Sweet. Wonder if this opens the door a DeCSS-style hack for open source iMessage clients?

1vuio0pswjnm7• 2 years ago

Actual paper:

https://gofetch.fail/files/gofetch.pdf

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

Related Stories