Apple chips can be hacked to leak secrets from Gmail, iCloud, and more
Apple chips can be hacked to leak secrets from Gmail, iCloud, and more
arstechnica.com
Apple chips can be hacked to leak secrets from Gmail, iCloud, and more
33 comments
-
-
I need a bigger nerd than me to explain how much Apple users need to worry about this.
-
Very. It's unpatchable. It's taking advantage of a speculative execution flaw, which is baked into the CPU microcode. This is the Apple M-chip version of Spectre/Meltdown that happened on x86 CPUs a few years ago.
The best Apple can do is attempt to add some code to the OS to help prevent this issue, but if Spectre was any example, it'll cause a hit to the CPU performance.
-
The researchers published a list of mitigations they believe will address the vulnerabilities allowing both the FLOP and SLAP attacks. They said that Apple officials have indicated privately to them that they plan to release patches.
So this'll likely be mitigated soon, and while you're probably right about the performance hit (which will likely be minor), I don't think (most) Apple users need to be very worried about this.
-
Oh, yet another speculative execution flaw...
-
-
This is a real problem, and Apple can’t patch it out of the hardware. The only thing they can do is write software to run in advance of hardware execution to “randomize” when and where memory is written to and read from. That will slightly decrease the performance of these chips. The “older” chips from 2021 would see the worst performance reduction. M3 users probably won’t even be able to tell.
The attack vector is a web browser. Even a completely updated safari is vulnerable, but Chrome is seemingly easier to exploit (the way browsers store website data in memory is the key). An encrypted browser won’t change anything because the attack is reading the unencrypted data being displayed to the user.
It takes several minutes for a compromised website to perform the attack. So basic sense practices apply. If you think a website is unsafe, don’t open it. If you think something is happening, closing the suspicious sites immediately might stop the attack before any damage is done. I don’t know how easy it would be to compromise a trusted site, but it’s been done in the past.
Apple could potentially patch Safari to do things that make it harder for the attack to work correctly, and you can bet they’re already retooling the next generation of processors to get rid of this exploit. They did the same thing when an unpatchable exploit was found in the M1 series, M2s have a stopgap measure, and M3s were redrawn to make it an nonissue.
-
The main issue with these vulnerabilities is a loss in performance when the microcode patch gets applied.
On a more philosophical note, it's also a trend to release insecure products to tout performance metrics. Intel did it. Now it's apple's turn.
Don't trust corporations, ever.
-
-
FYI
“ They also said they don't know if browsers such as Firefox are affected because they weren't tested in the research.”
Seems you should be fine if you follow the usual protocols though: don’t open suspicious links, check urls, that sort of thing. I expect a frantic phone call from my mother-in-law who has an iPhone 8 any minute now…
-
Run an adblocker. Seriously, ads are nothing but other websites in the same browser - exactly the kind of thing that is the basis of this problem.
-
-
FLOP abuses the LVP in a way that allows the attacker to run functions with the wrong argument—for instance, a memory pointer rather than an integer.
is this a vulnerability in the software? So patching this won't require disabling speculative execution?
-
Hardware. There's a load value predictor that guesses the value of a load from memory
-
-
But-but I was told Apple's security was the very best! That's why they charge so much for everything they make, right? ... Right?
-
We can laugh all we want but this issue was present on x86 hardware first
https://thehackernews.com/2024/10/new-research-reveals-spectre.html?m=1
-
-
opens up a little notepad titled "Reasons to NOT buy Apple"
-
Then you probably don't know about Spectre and Meltdown from a few years ago. Same family of problem on x86-64 (so Intel and AMD chips).
-
Wasn't it that those bugs were public knowledge by the time M1 was starting to sell? I guess recalls or delays to revenue are not acceptable.
Trophy for Apple being the first one to bring these speculative execution side channel attacks to Arm, because I've never heard of other cases. Ifi missed that please share enough details that I can find a white paper about it, because I don't read those kind of news from media.
-
-
33 comments
Speculative execution seems to be the source of a lot of security flaws in many different CPUs. CPU manufacturers seem to be so focused on winning the performance race that security aware architecture design takes the backseat.
Also, it's more and more clear that it's a bad idea that websites can just execute arbitrary code. The JS APIs are way too powerful and complex nowadays. Maybe websites and apps should've stayed separate concepts instead of merging into "web apps".
I also wonder if it'd be possible to design a CPU so vulnerabilities like these are fixable instead of just "mitigable". Similar to how you can reprogram an FPGA. I have no clue how chip design works though, but please feel free to reply if you know more about this.
Being a Linux user I really like everything being ran in the browser. What if we just have more control of which JS APIs can be used? On a site by site bases. Which I assume can probably already be done with extensions.
Some browsers such as cromite disable JIT compilation and WebAssembly by default. Allowing you to opt-in to enable these features on a site by site bases.
JIT and WebAssembly have been the source of many high profile CVE in browser recently including the one mentioned in the post (well, this one is on Safari's Chrome).
relevant research
Javascript in general was a mistake, and always has been.
The web should've had Scheme or Python instead. Or better yet, we shouldn't have given up so quickly on Java Web Start because then we could've had proper web applications with their own windows and native UIs and such.
Damn straight!
Oh no, not python!
Fast for the benchmarks. "We'll make it slower and safer later."
Take a look at ARM Morello and CHERI.