What do you want to achieve by using this kind of ad absurdum reasoning? Of course the private keys should stay private (that’s why they are called private). What I still don’t understand however is which of many private keys secured on my Mac could be retrieved using this exploit. To rephrase the question: which common cryptographic service with a known algorithm could be targeted by this type of attack.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Silicon Vulnerability Allows Hackers to Extract Encryption Keys
- Thread starter MacRumors
- Start date
- Sort by reaction score
What do you want to achieve by using this kind of ad absurdum reasoning? Of course the private keys should stay private (that’s why they are called private). What I still don’t understand however is which of many private keys secured on my Mac could be retrieved using this exploit. To rephrase the question: which common cryptographic service with a known algorithm could be targeted by this type of attack.
What do you want to achieve by using this kind of ad absurdum reasoning? We don't know what we don't know. You ever try to prove something did NOT happen. You still did not answer the question. If they don't matter, as you seem to imply, then why keep them private? Oh, I got your answer, "Just because." Which is not good enough.
M3 has it too.
You will need M4... or knowing Apple, M8 by the time they bother to fix it.
Now I am really very curious to see the source code for this exploit. The authors have promised to release it, so far their repository is empty. There has been some speculation that they are running the code under Asahi, and if this is true, it is possible that the exploit does not work under macOS at all. One thing that confused me from the start is the requirement to run the exploit and the cryptographic function on the same L2 cluster. However, when I was testing Apple CPU behavior, I observed that the threads were periodically moved between clusters (probably to avoid the long tail effect). Given the fact that macOS does not allow you to pin threads to CPU cores it would be interesting to see whether this type of attack is even possible under macOS scheduler.
Yes. Gives many agencies around the world a back door to extract information from your devices.
I'd think that an agency that can hack around OS restrictions to run CPU-heavy code on your machine for a few hours without you ever noticing will also have the means of getting access to your keys without resolving to this particular exploit
Sure. So ? It’s easier for them with yet another exploit isn’t it?I'd think that an agency that can hack around OS restrictions to run CPU-heavy code on your machine for a few hours without you ever noticing will also have the means of getting access to your keys without resolving to this particular exploit
Is it? I mean, if you already gained access to the system at a level that allows you injecting arbitrary code into system libraries, why not just copy the certificates directly and be done with it?
Because they want to do more? They want more remote control under different circumstances. Why is this so hard to understand that another attack vector is bad.
What I am trying to say is that if an exploit requires the attacker to have keys to your house, it's not much of an added risk. Does it really matter if they use that key to dig a hole from your basement to the nearest canalization and then rob your house, or whether they rob your house immediately?
It does. Analogy: They may actually go into your house with physical keys, install hidden cameras and then close your home, lock it. They go back and observe you from afar. You may not even know they are continuously monitoring you. They may come back thru the basement later.
Every vulnerability matters.
so Apple has quickly released a Mac update for Sonoma 14.4.1 yesterday... did they disable this exploit while slowing down the performance of M1 or M2 chips ?
any way you look at this it is not a good thing for any of us on M series chips. This also affects other chips like intel etc.
For those who think this could be only directed to a specific targeted audience of M series users is dreaming...if you wanted a large scale attack the simplest method would be, just via a script on a webpage that downloads a payload just by browsing then the attacker controls the payload remotely to attack the cpu. The other option someone download software with the exploit embedded and then they are infected with C & C and they are remotely attacked as well.
Then you also have those third party apps that could have their supply chain infected with this exploit and you unknowingly download it and execute while they are remotely accessing your Mac.
I'm also concerned about the 2 things:
1 - if apple patches it what is the performance hit on M1, M2 & M3 chips
2- did apple patch it with the latest update from yesterday in 14.4.1 and also patches for Ventura?
any way you look at this it is not a good thing for any of us on M series chips. This also affects other chips like intel etc.
For those who think this could be only directed to a specific targeted audience of M series users is dreaming...if you wanted a large scale attack the simplest method would be, just via a script on a webpage that downloads a payload just by browsing then the attacker controls the payload remotely to attack the cpu. The other option someone download software with the exploit embedded and then they are infected with C & C and they are remotely attacked as well.
Then you also have those third party apps that could have their supply chain infected with this exploit and you unknowingly download it and execute while they are remotely accessing your Mac.
I'm also concerned about the 2 things:
1 - if apple patches it what is the performance hit on M1, M2 & M3 chips
2- did apple patch it with the latest update from yesterday in 14.4.1 and also patches for Ventura?
There is no mention of this exploit in the patch notes.
It is also not clear whether the exploit works under macOS at all. The authors of the paper do not make it clear how exactly they do their tests. It does appear that their methodology involves features that are not supported under macOS (like pinning work to specific CPU cores). It has been speculated that they tested their exploit under Linux (Asahi). They have not published the code yet. It would make sense to wait and gather all the information before concluding that Macs are at risk.
And what then? What kind of keys would you try to steal using this method? Remember, the exploit requires access to a known cryptographic function (the attacker needs to know the exact algorithm and code of the function) and the ability to call that function continuously. Also, the cryptographic function and the exploit must run on the same CPU cluster and need to share their L2 cache. Not to mention that the attack takes a very long time. These are quite complex conditions to be met. As I was trying to make clear in this thread, I am not at all convinced that this exploit is practical, assuming it works on macOS to begin with.
The M3 has a programmable flag that turns off the DMP speculative execution. Developers of cryptographic applications and libraries can turn off the flag when running crypto code and turn it back on when the crypto code is complete. Those same developers are probably going to have to do other (currently unspecified?) mitigations to prevent this. It is likely that Apple added the flag to prevent attacks like this and considers the problem solved.
I find it bizarre, with small scale ransomware attacks against macOS on the rise, that users are so laze faire about a baked in security issue that can only be resolved by reducing the performance of the computer you paid so dearly for.
There will definitely be another class action suit against Apple for this issue. Apple advertises certain performance, sells a product based on that performance, then later says, "oh if you want a secure system we have to reduce the performance of your machine". Truth is the entire line should be recalled but that would put Apple out of business. How about holding the company responsible and getting what you pay for? Are you afraid they are going to go out of business and won't be able to fill your "new product" addiction? It seems people on this board are willing to just eat it and absolve Apple.
There will definitely be another class action suit against Apple for this issue. Apple advertises certain performance, sells a product based on that performance, then later says, "oh if you want a secure system we have to reduce the performance of your machine". Truth is the entire line should be recalled but that would put Apple out of business. How about holding the company responsible and getting what you pay for? Are you afraid they are going to go out of business and won't be able to fill your "new product" addiction? It seems people on this board are willing to just eat it and absolve Apple.
What are you talking about?…
They have done neither of these things (crypto performance).
As others have pointed out in this thread, no one is sure this ‘exploit’ even functions under macOS.
You are extrapolating quite a lot from a single academic paper that hasn’t yet been validated or reviewed. And I am really puzzled about what you say in regards to potential performance impact. There is no reason at all why closing this particular hole (assuming it is even exploitable on macOS) would have any performance impact on your software.
It'll be interesting to see how this develops. At first, I was going to add a MacBook Air M3. Then I was going to trade in/sell my Mac Mini M1, and get a MacBook Pro M3 Pro. Now I'm thinking I'll just sit tight, and see if it's fixed in the M4.
Most people are not really at risk from "agencies around the world". Criminals in their own town present a much greater risk and Apple's biggest security flaw is allowing an iOS device logged in to iCloud to change the iCloud account password without additional authentication even if the device is secured by a PIN.
Consider the steps that need to happen for this exploit to occur.
Anything that requires physical access or permission to install a processes is an edge case for me. Just not going to happen.
People share their online banking OTP with scammers and lose their cash so anything is possible. But gross negligence of actions is too high of a bar to control.
Not gonna set the bar to the point where negligence of the user is the standard of protection required.
What do you think? You concerned?
...And then they use your infected computer to gain access to the organisation you work for right? From there they infect every employee connected to the corporate network.... and so on....
Consider the risk vs the likelihood of what you're suggesting can happen. Yeah it's possible, but likely? Nope.
This is a troll right? 100% secure against all current and future risks else a class action?
Ease up on the jack hammering. Let's see if this is even possible to exploit in the wild before we lose our rocks. Could turn out to be a controlled lab experiment.
That’s your opinion. It’s been proven wrong many times. People who do it don’t care for the “risk”.