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.

Technically, it’s a vulnerability but...

Martin said that the flaw is mainly harmless because it can't be used to infect a Mac and it can't be used by exploits or malware to steal or tamper with data stored on a machine. Rather, the flaw can be abused only by two or more malicious apps that have already been installed on a Mac through means unrelated to the M1 flaw.

 

Still, the bug, which Martin calls M1racles, meets the technical definition of a vulnerability. As such, it has come with its own vulnerability designation: CVE-2021-30747.

 

"It violates the OS security model," Martin explained in a post published Wednesday. "You're not supposed to be able to send data from one process to another secretly. And even if harmless in this case, you're not supposed to be able to write to random CPU system registers from userspace either."

 

Other researchers with expertise in CPU and other silicon-based security agreed with that assessment.

 

"The discovered bug cannot be used to infer information about any application on the system," said Michael Schwartz, one of the researchers who helped discover the more serious Meltdown and Spectre vulnerabilities in Intel, AMD, and ARM CPUs. "It can only be used as a communication channel between two colluding (malicious) applications."

 

He went on to elaborate:

The vulnerability is similar to an anonymous "post office box", it allows the two applications to send messages to each other. This is more or less invisible to other applications, and there is no efficient way to prevent it. However, as no other application is using this "post office box", no data or metadata of other applications is leaking. So there is the limitation, that it can only be used as a communication channel between two applications running on macOS. However, there are already so many ways for applications to communicate (files, pipes, sockets, ...), that one more channel doesn't really impact the security negatively. Still, it is a bug that can be abused as an unintended communication channel, so I think it is fair to call it a vulnerability.

A covert channel might be of more consequence on iPhones, Martin said, because it could be used to bypass sandboxing that's built into iOS apps. Under normal conditions, a malicious keyboard app has no means to leak key presses because such apps have no access to the Internet. The covert channel could circumvent this protection by passing the key presses to another malicious app, which in turn would send it over the Internet.

 

Even then, the chances that two apps would pass Apple's review process and then get installed on a target's device are farfetched.

Why the heck is a register accessible by EL0?

The flaw stems from a per-cluster system register in ARM CPUs that's accessible by EL0, a mode that's reserved for user applications and hence has limited system privileges. The register contains two bits that can be read or written to. This creates the covert channel, since the register can be accessed simultaneously by all cores in the cluster.

 

Martin wrote:

A malicious pair of cooperating processes may build a robust channel out of this two-bit state, by using a clock-and-data protocol (e.g., one side writes 1x to send data, the other side writes 00 to request the next bit). This allows the processes to exchange an arbitrary amount of data, bound only by CPU overhead. CPU core affinity APIs can be used to ensure that both processes are scheduled on the same CPU core cluster. A PoC demonstrating this approach to achieve high-speed, robust data transfer is available here. This approach, without much optimization, can achieve transfer rates of over 1MB/s (less with data redundancy).

 

Martin has provided a demo video here.

 

M1RACLES: Bad Apple!! on a bad Apple (M1 vulnerability).

It's not clear why the register was created, but Martin suspects that its access to EL0 was an error rather than intentional. There is no way to patch or fix the bug in existing chips. Users who are concerned about the flaw have no other recourse than to run the entire OS as a properly configured virtual machine. Because the VM will disable guest access to this register, the covert channel is killed. Unfortunately, this option has a serious performance penalty.

 

Martin stumbled on the flaw as he was using a tool called m1n1 in his capacity as the lead manager for Asahi Linux, a project that aims to port Linux to M1-based Macs. He initially thought the behavior was a proprietary feature, and as such, he openly discussed it in developer forums. He later learned that it was a bug that even Apple developers hadn't known about.

 

Again, the vast majority of Mac users—probably higher than 99 percent—have no reason for concern. People with two or more malicious apps already installed on their machine have much bigger worries. The vulnerability is more notable for showing that chip flaws, technically known as errata, reside in virtually all CPUs, even new ones that have the benefit of learning from previous mistakes made in other architectures.

 

Apple didn't respond to a request for comment, so it's not yet clear if the company has plans to fix or mitigate the flaw in future generations of the CPU. For those interested in more technical details, Martin's site provides a deep dive.