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.
Ars Technica
This story originally appeared on Ars Technica, a trusted source for technology news, tech policy analysis, reviews, and more. Ars is owned by WIRED’s parent company, Condé Nast.
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.
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.
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).