Apple's M1 has an unfixable security flaw that's effectively harmless

[Realityck]

Apple's M1 has an unfixable security flaw that's effectively harmless - Engadget 5/28​

Apple's M1 chip has a vulnerability that can't be fixed without a silicon revision, according to developer Hector Martin. The flaw allows for covert channels that enable two malicious apps to talk to each other. However, unless your system has been compromised by exploits or malware through other means, "covert channels are completely useless," Martin wrote in a blog post that was first spotted by Ars Technica.​

From Ars Technica

Apple's new M1 CPU has a flaw that creates a covert channel that two or more malicious apps—already installed—can use to transmit information to each other, a developer has found.

The surreptitious communication can occur without using computer memory, sockets, files, or any other operating system feature, developer Hector Martin said. The channel can bridge processes running as different users and under different privilege levels. These characteristics allow for the apps to exchange data in a way that can't be detected—or at least without specialized equipment.

​

 

[Kung gu]

Many CPU's have security flaws. It will probably be revised in the A15/16 designs.

 

[Apple_Robert]

M1 security flaw

https://www.phonearena.com/news/apple-m1-security-vulnerability_id132376 True or not? Guess my iPhone 12 is safe although it has a flaw as well but I won’t be getting iPad with M1 as I do lots of banking online... “Apple has been made aware of the issue and the company has acknowledged it.”...

forums.macrumors.com

 

[velocityg4]

Well there go my plans to install multiple malware on an M1. Since they could communicate with each other covertly.

 

[waloshin]

You just might do so without knowing. Free software… downloading free movies etc…

 

[bobcomer]

And it does break the security model. Not a big concern, but a concern.

I wonder why it can't be mitigated by the OS...

 

[jdb8167]

And it does break the security model. Not a big concern, but a concern.

I wonder why it can't be mitigated by the OS...

It’s a register. How would you mitigate it without the required hardware support?

Edit: I guess the OS could scan binaries looking for the register and refuse to load the application if it finds it.

 

[bobcomer]

It’s a register. How would you mitigate it without the required hardware support?

Edit: I guess the OS could scan binaries looking for the register and refuse to load the application if it finds it.

I really wouldn't hazard a serious guess, I'm just a user when it comes to Macs, but it seems to be that watching for certain access is what some AV software does.

 

[jdb8167]

I really wouldn't hazard a serious guess, I'm just a user when it comes to Macs, but it seems to be that watching for certain access is what some AV software does.

It’s a register. The bandwidth is way, way too high for any periodic check to make much difference.

 

[bobcomer]

It’s a register. The bandwidth is way, way too high for any periodic check to make much difference.

Well, I guess have to see what Apple does. (though I agree periodic would be a silly way to do it.)

 

[Sydde]

And it does break the security model. Not a big concern, but a concern.

I wonder why it can't be mitigated by the OS...

It probably could. They could schedule a core to interrupt frequently just to reset the value of the register. It would be fairly low overhead, but it would corrupt any data transfers that might be happening, because the register can effectively only transfer one bit at a time.

App store apps must be sent to Apple as llvm-ir, so this vulnerability will sim0,y not exist in the app store since Apple control the final build. They could move this operation to each computer/device and institute a protocol that prevents the system from using any code that it has not itself built, which would greatly reduce malware access to macOS.

 

[Significant1]

It probably could. They could schedule a core to interrupt frequently just to reset the value of the register. It would be fairly low overhead, but it would corrupt any data transfers that might be happening, because the register can effectively only transfer one bit at a time.

It would just be noise and reduce the bandwith, not close it. The demo video already show lost bits.

 

[jdb8167]

It would just be noise and reduce the bandwith, not close it. The demo video already show lost bits.

Exactly. It isn’t like writing an error correcting protocol is hard. Remember this takes cooperation between two applications.

I also think developers would reject the idea of not allowing native binaries. That sounds too intrusive and people would just work around it anyway. Users can choose to only install from the App Store right now if they want that level of protection.

 

[Sydde]

Reading and writing the particular register are very specific 32-bit bit patterns. All ARM instructions are 32-bit bit patterns, in a fixed, regular array. Thus, the OS itself could easily, quickly scan code for the MSR/MRS instructions that target this register. In general, user-level code should not be accessing SPSRs and should never be seen using a MSR instruction at all, so it should be nearly trivial for the OS to vet code before putting it in an executable code page.