New 'GoFetch' Apple CPU Attack Exposes Crypto Keys (securityweek.com) 40
"There is a new side channel attack against Apple 'M' series CPUs that does not appear to be fixable without a major performance hit," writes Slashdot reader EncryptedSoldier. SecurityWeek reports: A team of researchers representing several universities in the United States has disclosed the details of a new side-channel attack method that can be used to extract secret encryption keys from systems powered by Apple CPUs. The attack method, dubbed GoFetch, has been described as a microarchitectural side-channel attack that allows the extraction of secret keys from constant-time cryptographic implementations. These types of attacks require local access to the targeted system. The attack targets a hardware optimization named data memory-dependent prefetcher (DMP), which attempts to prefetch addresses found in the contents of program memory to improve performance.
The researchers have found a way to use specially crafted cryptographic operation inputs that allow them to infer secret keys, guessing them bits at a time by monitoring the behavior of the DMP. They managed to demonstrate end-to-end key extraction attacks against several crypto implementations, including OpenSSL Diffie-Hellman Key Exchange, Go RSA, and the post-quantum CRYSTALS-Kyber and CRYSTALS-Dilithium. The researchers have conducted successful GoFetch attacks against systems powered by Apple M1 processors, and they have found evidence that the attack could also work against M2 and M3 processors. They have also tested an Intel processor that uses DMP, but found that it's 'more robust' against such attacks.
The experts said Apple is investigating the issue, but fully addressing it does not seem trivial. The researchers have proposed several countermeasures, but they involve hardware changes that are not easy to implement or mitigations that can have a significant impact on performance. Apple told SecurityWeek that it thanks the researchers for their collaboration as this work advances the company's understanding of these types of threats. The tech giant also shared a link to a developer page that outlines one of the mitigations mentioned by the researchers. The researchers have published a paper (PDF) detailing their work.
Ars Technica's Dan Goodin also reported on the vulnerability.
The researchers have found a way to use specially crafted cryptographic operation inputs that allow them to infer secret keys, guessing them bits at a time by monitoring the behavior of the DMP. They managed to demonstrate end-to-end key extraction attacks against several crypto implementations, including OpenSSL Diffie-Hellman Key Exchange, Go RSA, and the post-quantum CRYSTALS-Kyber and CRYSTALS-Dilithium. The researchers have conducted successful GoFetch attacks against systems powered by Apple M1 processors, and they have found evidence that the attack could also work against M2 and M3 processors. They have also tested an Intel processor that uses DMP, but found that it's 'more robust' against such attacks.
The experts said Apple is investigating the issue, but fully addressing it does not seem trivial. The researchers have proposed several countermeasures, but they involve hardware changes that are not easy to implement or mitigations that can have a significant impact on performance. Apple told SecurityWeek that it thanks the researchers for their collaboration as this work advances the company's understanding of these types of threats. The tech giant also shared a link to a developer page that outlines one of the mitigations mentioned by the researchers. The researchers have published a paper (PDF) detailing their work.
Ars Technica's Dan Goodin also reported on the vulnerability.
Re:wow (Score:5, Informative)
Memory dependent prefetch is basically the problem with Spectre-BHI/BHB and Meltdown that hit Intel, AMD, and many of the common ARM core several years ago. It's a tough problem to implement good performance where execution throughput approaches memory bandwidth, and a system that doesn't easily leak information to a side channel attack.
The real pain in these flaws is that the root problem is so deeply ingrained into the processor architecture that software or microcode fixes aren't even possible.
I wish Apple well. Hackers have potentially given Apple a windfall by forcing security conscious customers to phase out hardware and buy new systems.
Re: wow (Score:1)
New *slower* systems, perhaps.
Re: (Score:3)
apple makes pretty crappy cpus
No shittier than Intel and AMD.
Get them bits hooter! (Score:2)
guessing them bits at a time by monitoring the behavior of the DMP
Get them bits hooter! Go on boy getem good boy
Why is there no permission for precise timers? (Score:2)
1ms resolution should be enough for vast majority of cases and if you have special need, you can ask user for permission / accept greater scrutiny for App Store reviews. Otherwise, no ability to time a single memory access.
Re: (Score:2)
Terrible week (Score:2)
This week hasn't been great for Apple and there's still one more day left. Oh boy.
Re: (Score:3)
On the other hand, Apple took in around $276,700,000 in net profit today, and will do so again tomorrow, and the next day, and so on for the forseeable future, so I think they'll be okay.
Re: (Score:1)
This. People buy the shittiest shiny thing based on marketing but not quality. Biggest proof: Windows.
Re: (Score:2)
On a bulk level yes. But Apple is a collection of employees and investors, each with different amounts and types of interests. Some of those Apple individuals are likely mad at it.
What Did You Expect? (Score:3, Funny)
The logo has a bite missing. At least they tell you their shit is jacked.
On the bright side (Score:4, Funny)
This probably means DRM can be compromised on M-core CPUs, too. That's cause for celebration!
Re: (Score:2)
> This probably means DRM can be compromised on M-core CPUs, too. That's cause for celebration!
And your bank account too. Cause for more celebration!
Not what I was expecting (Score:2)
tested an Intel processor that uses DMP, but found that it's 'more robust' against such attacks
Remembering all the Spectre/Meltdown hullabaloo of the before times, this statement elicited some giggling.
Re: Not what I was expecting (Score:1)
But Apple being Apple didn't and now here they are, not learning from others or history. Guess they figured it could never happen to them....
Nothing to see here (Score:4, Informative)
I of course can't find it now; but I swear I read that this requires Meatspace Direct Access, plus it takes hours or even days to extract a key; so it's unlikely to be exploited.
Here's an allusion to this limitation:
"DMP-style attacks are not common, and typically require physical access to a Mac."
https://www.macrumors.com/2024... [macrumors.com]
Re: Nothing to see here (Score:2)
Oh, let the Mac haters hate and have their fun.
I wonder how many read the article and made it to the last paragraph.
What this article doesn't do is state whether this attack requires physical access or can be performed simply by running a program from remote. It sounds like it.
They did indicate that it can take upwards of an hour to extract a key against the specific encryption program running on the machine.
Imagine that...your logged in laptop, running crypto software, in the hands of spies for an hour.
Re: (Score:2)
What this article doesn't do is state whether this attack requires physical access or can be performed simply by running a program from remote. It sounds like it.
I really did see a definitive statement that this exploit required physical access. I just can't remember which article that I read said that.
Those sidechain attacks are weird. Reminds me of some of the methods to read embedded microcontroller code from the onboard PROM/Flash with the "Protect bit" Set. Usually involved multiple Resets, while jiggering around with power supply voltages and the like.
Some people just have entirely too much Thyme on their Hams!
Re: Nothing to see here (Score:3)
Physical access isn't needed, you just need to be able to execute native code. Though last time we saw one of these speculative execution vulnerabilities on Apple hardware, somebody came up with a way to pull it off in JavaScript. Given they're just injecting fake pointers into the cache, that sounds achievable.
Re: (Score:2)
Physical access isn't needed, you just need to be able to execute native code. Though last time we saw one of these speculative execution vulnerabilities on Apple hardware, somebody came up with a way to pull it off in JavaScript. Given they're just injecting fake pointers into the cache, that sounds achievable.
But the high-resolution timers necessary aren't readily available, so. . .?
Plus, you have to get someone to hang-out on your Web Page for an hour or so. Most people get antsy after about 30 seconds!
Re: (Score:1)
But the high-resolution timers necessary aren't readily available, so. . .?
Given JS gets JIT compiled, and WASM is also a thing, I wouldn't count on this.
Plus, you have to get someone to hang-out on your Web Page for an hour or so. Most people get antsy after about 30 seconds!
This is a side-channel attack. That means the normal assumptions about what's necessary for cryptanalysis don't apply because you're no longer dealing with a black box. Simply because the researchers here couldn't pull it off in a shorter amount of time doesn't mean that this is impossible. Furthermore, it's easy to get people to spend that long on a page. Games, applications, hour long videos...The sky's the limit.
Re: (Score:3)
But the high-resolution timers necessary aren't readily available, so. . .?
Given JS gets JIT compiled, and WASM is also a thing, I wouldn't count on this.
Plus, you have to get someone to hang-out on your Web Page for an hour or so. Most people get antsy after about 30 seconds!
This is a side-channel attack. That means the normal assumptions about what's necessary for cryptanalysis don't apply because you're no longer dealing with a black box. Simply because the researchers here couldn't pull it off in a shorter amount of time doesn't mean that this is impossible. Furthermore, it's easy to get people to spend that long on a page. Games, applications, hour long videos...The sky's the limit.
Wrong.
LEBCAK: Limitation Exists Between Computer And Keyboard.
Most people are pining for the Browser's Back Button before even 2 bytes can be extracted. You might catch a few truly bored (or distracted) Users, but enough to make it worthwhile before you're caught?
Re: Nothing to see here (Score:1)
This is what you call wishful thinking.
"Why no, that's definitively wrong because apple fanboys always go for the back button with 20 milliseconds of opening a webpage! Apple devices cannot be exploited, this is impossible!"
Re: (Score:2)
This is what you call wishful thinking.
"Why no, that's definitively wrong because apple fanboys always go for the back button with 20 milliseconds of opening a webpage! Apple devices cannot be exploited, this is impossible!"
I never said "Apple fanboys"; because short attention span is pretty much universal among web surfing.
And I certainly never even implied that this had anything to do with this being Apple! If this had been a similar Vulnerability on a Snapdragon (which, BTW, may very-well exist), I would have thought it sounded pretty difficult to Exploit there, too.
It's the nature of the type of Vulnerability, regardless of who's Trained Sand it's running on, that likely diminishes the widespread threat here.
Got it?
Re: Nothing to see here (Score:2)
Snapdragon is just cortex, which it looks like they already examined.
Re: (Score:2)
So, basically any employee at any company could possibly do this to any machine?
Yeah, basically nothing to worry about, I'm sure.
Those keys are never worth protecting anyways.
Re: (Score:2, Insightful)
That was the case of Intel's Spectre vulnerability too, but it didn't take long for someone to figure out how to make it work in Javascript. Then it's just a matter of tricking the victim to stay on your web page for a while.
Depending on the key type, it can take only minutes to extract.
Re: (Score:2)
That was the case of Intel's Spectre vulnerability too, but it didn't take long for someone to figure out how to make it work in Javascript. Then it's just a matter of tricking the victim to stay on your web page for a while.
Depending on the key type, it can take only minutes to extract.
Hmmm. Well that sucks!
Hopefully, this Exploit won't succumb to that.
Re: (Score:2)
I see you have not given up your apple shilling regardless of how bad they fuck up
No, I am just calling as I sees it.
If this becomes remotely exploitable, then it certainly is a bigger deal; but if it takes minutes to hours to work, then again the threat is quite lessened.
Re: (Score:2)
Re: (Score:2)
Your history says otherwise. Basically you are almost certain to point the finger elsewhere or use a whataboutism to claim they are no worse. No matter what Apple do you defend them.
I calls 'em like I sees 'em.
BTW, funny that the less number of digits in the UserID, generally the more likely they are to have a similar viewpoint to mine regarding Apple Topics.
Anyone exploiting this in the wild? (Score:2)
Itâ(TM)s a timing attack, so it takes time. How much time exactly does it take to read my private keys? If it stays in the same memory location for an hour, a minute, a second, or a millisecond? I canâ(TM)t see a reason why a private key should be in RAM for more than some seconds.
So Iâ(TM)d recommend to Apple a new API that can read d
So w/o access, nothing happens... (Score:2)