You must log in or register to comment.
This requires local access to do and presently an hour or two of uninterrupted processing time on the same cpu as the encryption algorithm.
So if you’re like me, using an M-chip based device, you don’t currently have to worry about this, and may never have to.
On the other hand, the thing you have to worry about has not been patched out of nearly any algorithm:
The second comment on the page sums up what I was going to point out:
I’d be careful making assumptions like this ; the same was true of exploits like Spectre until people managed to get it efficiently running in Javascript in a browser (which did not take very long after the spectre paper was released). Don’t assume that because the initial PoC is time consuming and requires a bunch of access that it won’t be refined into something much less demanding in short order.
Let’s not panic, but let’s not get complacent, either.
I mean, unpatchable vulnerability. Complacent, uncomplacent, I’m not real sure they look different.
Can’t fix the vulnerability, but can mitigate by preventing other code from exploiting the vulnerability in a useful way.
That’s the sentiment I was going for.
There’s reason to care about this but it’s not presently a big deal.
Sure. Unless law enforcement takes it, in which case they have all the time in the world.
Yup, but they’re probably as likely to beat you up to get your passwords.
Apple is not a secure ecosystem.
No system is free from vulnerabilities.
No system is perfect, sure, but rolling their own silicon was sorta asking for this problem.
As opposed to what? Samsung, Intel, AMD and NVIDIA and others are also “rolling their own silicon”. If a vulnerability like that was found in intel it would be much more problematic.
This particular class of vulnerabilities, where modern processors try to predict what operations might come next and perform them before they’re actually needed, has been found in basically all modern CPUs/GPUs. Spectre/Meldown, Downfall, Retbleed, etc., are all a class of hardware vulnerabilities that can leak crypographic secrets. Patching them generally slows down performance considerably, because the actual hardware vulnerability can’t be fixed directly.
It’s not even the first one for the Apple M-series chips. PACMAN was a vulnerability in M1 chips.
Researchers will almost certainly continue to find these, in all major vendors’ CPUs.
How much slower is s CPU without this functionality built in?
The patch for meltdown results in a performance hit of between 2% and 20%. It’s hard to pin down an exact number because it varies both by CPU and use case.
Also the article states it is found in intels chips too. So not really any better if they had stayed on that pathway either
I’ve just finished reading the article, it does not say this. It says Intel also has a DMP but that only Apple’s version has the vulnerability.
Wow, what a dishearteningly predictable attack.
I have studied computer architecture and hardware security at the graduate level—though I am far from an expert. That said, any student in the classroom could have laid out the theoretical weaknesses in a “data memory-dependent prefetcher”.
My gut says (based on my own experience having a conversation like this) the engineers knew there was a “information leak” but management did not take it seriously. It’s hard to convince someone without a cryptographic background why you need to {redesign/add a workaround/use a lower performance design} because of “leaks”. If you can’t demonstrate an attack they will assume the issue isn’t exploitable.
So the attack is (very basically, if I understand correctly)
Setup:
- I control at least one process on the machine I am targeting another process on
- I can send data to the target process and the process will decrypt that
Attack:
- I send data that in some intermediate state of decryption will look like a pointer
- This “pointer” contains some information about the secret key I am trying to steal
- The prefetcher does it’s thing loading the data “pointed to” in the cache
- I can observe via a cache side channel what the prefetcher did, giving me this “pointer” containing information about the secret key
- Repeat until I have gathered enough information about the secret key
Is this somewhat correct? Those speculative execution vulnerabilities always make my brain hurt a little
“Govt-mandated backdoor in Apple chips revealed”
There, fixed that for you.
Any chance of recall?
Nope since it’s an intended feature.
Oops
Whoopsie
