Apple silicon vulnerability

I have no idea what this means, details in this article

May be someone can translate

1 Like

tl;dr - sounds like data from one app could basically be leaked into another app that’s acting nefariously.

Let’s say you open passwords.txt in Textedit (a bad idea on so many levels!). Theoretically that memory with passwords.txt stored in it should be “locked” to Textedit. It has to be read from disk into memory, modified, then written back out to disk when you’re done.

Some hacks can basically get in the middle of that read/write process, and when Textedit reads/writes that data, they can sniff it and get data out.

This is more like “Textedit has it loaded into memory, and because of some weirdness about how Apple Silicon does things another app could theoretically read that memory”.

If I’m understanding it correctly, it’s almost the exact inverse of a buffer overflow attack. Instead of using bad pointers to write data where it shouldn’t go, they’re using bad pointers to read data from an otherwise-compartmentalized area of RAM. :slight_smile:


thanks @webwalrus , for average users, if there anything we should be aware or do ? If this is hardware related, is a software firmware upgrade able to fix or reduce the impact

There’s nothing you can do. Apple would have to address it in a software update when / if they determine it to be a serious enough issue.

It seems to be a reminder, that it might be wise to use only apps from thrusted sources!


As I recall the vulnerabilities found in Intel chips a few years ago couldn’t be fixed in software without a significant performance penalty in some cases. A permanent solution would require a chip redesign. Hopefully that’s not the case here.

1 Like

Yeah, it was a non-trivial performance hit with Intel because basically they had to fix a hardware problem in software.

Reading other articles on this it sounds like the issue is rather limited, and that it would be rather difficult to exploit. But given that Apple is designing the chips themselves, they’d have enough control over the entire software/hardware stack to theoretically implement a direct fix in future chip generations.

From the conclusion of the paper:

“Thankfully, many particularly worrying scenarios like JavaScript sandboxes al- ready assume that an adversary can leak any value in the virtual address space. These systems are unlikely to have significant security impacts from the M1 DMP.”

This makes me feel better (at the moment) about this, since any non-trivial webpage is essentially an untrusted application (itself built from a whole stack of untrusted code) that gets executed when you view it.

1 Like