Apple’s new M1 CPU has a flaw that creates a hidden channel that two or more malicious apps — already installed — can use to send information to each other, a developer has discovered.
The covert communication can take place without using computer memory, sockets, files or any other function of the operating system, developer Hector Martin said. The channel can bridge processes running as different users and under different privilege levels. These features allow the apps to exchange data in a way that cannot be detected, or at least without specialized equipment.
Technically it’s a vulnerability, but…
Martin said the flaw is mostly 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. Instead, the flaw can only be exploited by two or more malicious apps already installed on a Mac in a way unrelated to the M1 flaw.
Still, the bug, which Martin calls M1racles, meets the technical definition of a vulnerability. As such, it has been given its own vulnerability designation: CVE-2021-30747.
“It violates the operating system’s security model,” Martin explained in a post published Wednesday. “You’re not supposed to be able to secretly send data from one process to another. And even if it’s harmless in this case, don’t write to arbitrary CPU system registries from user space 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 an application on the system,” said Michael Schwartz, one of the researchers who helped discover the more serious Meltdown and Specter vulnerabilities in Intel, AMD, and ARM CPUs. “It can only be used as a communication channel between two colluding (malicious) applications.”
He continued:
The vulnerability is similar to an anonymous “mailbox”, allowing 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, since no other application uses this “mailbox”, no data or metadata from other applications is leaked. 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 in which applications can communicate (files, pipes, sockets, …) that an extra channel does not really negatively affect security. Still, it’s a bug that can be exploited as an unintended communication channel, so I think it’s fair to call it a vulnerability.
A hidden channel could be of more interest to iPhones, Martin said, as it could be used to bypass sandboxing built into iOS apps. Under normal circumstances, a malicious keyboard app has no way of leaking keystrokes because such apps cannot access the internet. The secret channel could bypass this protection by passing the keystrokes to another malicious app, which would in turn send them over the internet.
Even then, the chances of two apps passing Apple’s review process and then being installed on a target’s device is far-fetched.
Why the hell is a registry accessible to EL0?
The error stems from a system registry per cluster in ARM CPUs that is accessible by EL0, a mode reserved for user applications and therefore has limited system privileges. The register contains two bits that can be read or written. This creates the secret channel, as the registry is accessible to all cores in the cluster simultaneously.
martin wrote:
A malicious pair of collaborating processes can build a robust channel out of this two-bit state, using a clock-and-data protocol (e.g. one side writes 1x to send data, the other side writes 00 to the next bit to request) . This allows the processes to exchange any 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 fast, robust data transfer is available here. This approach can achieve transfer rates in excess of 1MB/s (less with data redundancy) without much optimization.
Martin has provided a demo video here.
M1RACLES: Bad Apple!! on a bad Apple (M1 vulnerability)†
It’s not clear why the registry was created, but Martin suspects that the access to EL0 was an error rather than intentional. There is no way to patch or fix the bug in existing chips. Users concerned about the error have no other option but to run the entire operating system as a properly configured virtual machine. Since the VM will disable guest access to this registry, the secret channel will be disabled. Unfortunately, this option comes with a serious performance penalty.
Martin encountered the error when he used a tool called m1n1 in his capacity as lead manager for Asahi Linux, a project aimed at porting Linux to M1-based Macs. He initially thought the behavior was a feature of its own, and as such he discussed it openly on developer forums. He later found out that it was a bug that even Apple developers didn’t know about.
Again, the vast majority of Mac users – probably more than 99 percent – have no cause for concern. People with two or more malicious apps already installed on their computers have much bigger concerns. The vulnerability is more notable because it demonstrates that chip errors, technically known as errata, exist in virtually all CPUs, even new ones that have the advantage of learning from previous errors made in other architectures.
Apple hasn’t responded to a request for comment, so it’s not yet clear whether 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 offers a deep dive.