Here is one for Steve. To be honest, I’m not sure that this is as bad as it sounds and a couple of things sound a little off.
- The problem is in the ARM extension for encrypted/checksummed pointers - the memory space address uses less than the allotted 64-bits, so the remaining bits are an encrypted checksum, to ensure the pointer hasn’t been tampered with. This is an ARM technology that Apple have implemented.
- It is claimed that the M1 is vulnerable, because it is the first desktop class processor to implement it. The problem I have with that is, ARM is still rare on the desktop, but is used in hundreds of IoT and mobile processors, as well as server processors.
i. Do any of them have this technology?
ii. Are any of them vulnerable?
iii. What about the A-series chips, from which the M-series are derived? Do they have this protection?
- Is it Apple’s implementation or is it a flaw in the specification?
I would be interested to hear what Steve has to say.
This sounds more like a Spectre/Meltdown type of flaw, it is a significant hardware flaw that can’t be easily fixed, but it isn’t that critical, because:
- you have to be able to execute code locally on the device, so you have already been able to install your code. Yes, it does theoretically mean you could jump from User Space into Kernel Space and get the privileges that implies.
- It is “slow”, you need several minutes to be able to work out the encryption key used to generate the hash.
- Once you have worked out the key, you have broken the pointer authentication, so you now have the same level of access you would on a chip without this technology (E.g. Qualcomm Snapdragon, Samsug Exynos etc.) - i.e. you are no worse off than using a chip without pointer protection, just that it took you longer to get to that level of access, because you had to jump the PA hurdle.
There are too many unanswered questions in the article and too much hyperbole around the M1 being the first “desktop chip” to use this, important is: is it the first/only ARM chip to use this? And is it an ARM problem or an Apple implementation problem?
The researchers/the article don’t provide any information about either of these critical pieces to the puzzle. Great work finding the flaw, but they stopped after only doing half the job, IMHO…