Apple’s new M1 CPU has a bug that creates a hidden channel through which two or more already installed malicious apps can transmit information to each other, as a developer has discovered.
The sneak communication can occur without the use of computer memory, sockets, files, or other operating system functions of the developer Hector Martin said. The channel can bridge processes that are executed as different users and with different authorization levels. These properties allow the apps to exchange data in ways that cannot be detected – or at least without special equipment.
Technically it’s a security flaw, but …
Martin said the bug is mostly harmless as it cannot be used to infect a Mac, and it cannot be used by exploits or malware to steal or tamper with data stored on a computer. Rather, the error can only be abused by two or more malicious apps that have already been installed on a Mac in a way that has nothing to do with the M1 error.
However, the bug that Martin mentions M1racles fits the technical definition of a security vulnerability. As such, it has its own vulnerability label: CVE-2021-30747.
“It violates the security model of the operating system,” said Martin in a post published on Wednesday. “You shouldn’t be able to secretly send data from one process to another. And even if it’s harmless in this case, you shouldn’t be able to write to random CPU system registers from user space either. “
Other researchers with expertise in CPU and other silicon-based security agreed with this assessment.
“The detected bug cannot be used to infer information about an application on the system,” said Michael Schwartz, one of the researchers who helped identify the more serious Meltdown and Specter vulnerabilities in Intel, AMD and ARM CPUs to discover. “It can only be used as a communication channel between two colluding (malicious) applications.”
He went on to explain:
The vulnerability is similar to an anonymous “mailbox”. It enables 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, because no other application is using this “mailbox,” no data or metadata from other applications is lost. 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 communication options for applications (files, pipes, sockets, …) that another channel does not really have a negative impact on security. Nevertheless, it is a bug that can be misused as an unintentional communication channel. I think it’s fair to call it a security hole.
A covert channel could be of more concern on iPhones, Martin said, as it could be used to bypass sandboxing built into iOS apps. Under normal conditions, a malicious keyboard app cannot lose keystrokes because such apps do not have access to the internet. The covert channel could bypass this protection by forwarding the keystrokes to another malicious app, which in turn sends them over the internet.
Even then, the likelihood that two apps will pass Apple’s verification process and then be installed on a target’s device is far-fetched.
Why the hell is a register accessible to EL0?
The error can be traced back to one system register per cluster in ARM CPUs that EL0 can access. This mode is reserved for user applications and therefore has only limited system rights. The register contains two bits that can be read or written to. This creates the hidden channel because all cores in the cluster can access the registry at the same time.
A malicious pair of cooperating processes can build a robust channel from 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 request the next bit ). . This allows the processes to exchange any amount of data that is only bound by the CPU overhead. CPU core affinity APIs can be used to ensure that both processes are scheduled on the same CPU core cluster. A PoC that demonstrates this approach to achieve fast and robust data transmission is available here. This approach can achieve transfer rates of over 1 MB / s without great optimization (less with data redundancy).
Martin has made a demo video available here.
It’s not clear why the registry was created, but Martin suspects that accessing EL0 was more of a bug than intended. There is no way to patch or fix the bug in existing chips. Users concerned about the failure have no choice but to run the entire operating system as a properly configured virtual machine. Since the VM deactivates guest access to this register, the hidden channel is terminated. Unfortunately, this option has a severe performance hit.
Martin stumbled upon the bug when, in his capacity as lead manager for Asahi Linux, he was using a tool called m1n1, a project aimed at porting Linux to M1-based Macs. At first he thought the behavior was a proprietary feature, and as such, he openly discussed it on 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 greater than 99 percent – have nothing to worry about. People with two or more malicious apps already installed on their computer are much more worried. The vulnerability is more notable because chip errors, technically known as errata, are present in virtually all CPUs, including new ones, which have the advantage of learning from previous errors in other architectures.
Apple hasn’t responded to a request for comment, so it’s not yet clear whether the company plans to fix or mitigate the bug in future generations of the CPU. For those interested in more technical details, Martin’s website offers a deep dive.