Unfixable Apple M1 chip bug enables cross-process chatter, breaking OS security model

M1RACLES flaw embarrassing, not that dangerous

Apple's Arm-based M1 chip, much ballyhooed for its performance, contains a design flaw that can be exploited to allow different processes to quietly communicate with one another, in violation of operating system security principles.

M1RACLES, as the bug has been called, doesn't pose a major security risk because information leakage is already possible through a variety of other side channels and inter-process communication. It does, however, add another way for malware already running on affected hardware to conduct covert communication.

In other words, it's more embarrassing – and a reminder that chips have quirks and bugs just like software – than dangerous.

The flaw arises from the fact that the Arm system register encoded as s3_5_c15_c10_1 contains two bits that can be read and written at EL0 (Exception Level 0, application level privilege) from all cores simultaneously. In a secure system, cross-process chatter is restricted to keep secrets from being revealed.

"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)," explains Hector Martin, founder and project lead of Asahi Linux, in his vulnerability disclosure. "This allows the processes to exchange an arbitrary amount of data, bound only by CPU overhead."

The cross-talk isn't particularly fast – data transfer rate is said to be a bit more than 1MB/s. Other information leakage side channels are often similarly slow.

Martin has published a proof-of-concept script to demonstrate how to read and write data to the overly talkative system register and a proof-of-concept script for setting up a covert channel on an M1 system. Apple, he says, was informed of the bug 90 days before he released his findings and issued a CVE-2021-30747 in response.

The M1 flaw affects macOS Big Sur, Linux v5.13+, and iOS/iPadOS, via the A14 chip, which according to Martin shares the same vulnerability.

Privacy promised?

Martin suggests that exploitation on iOS could be used to defeat privacy protections, noting that a malicious keyboard app might be able to function as a keylogger by sending typed text to another malicious app that could then forward the info to the internet. However, he says Apple's limitations on building code at runtime mean that the company could find exploit attempts if it subjected App Store submissions to static analysis.

The vulnerability can be dealt with by using a virtual machine, because hypervisors disable guest access to the vulnerable register by default, but otherwise there aren't a lot of good options, particularly on macOS.

"Mitigating the problem requires running your OS at EL1, where the problem register can be disabled, and then having at least some kind of minimal hypervisor at EL2 to deal with those traps (otherwise running an app that uses the register would just crash your machine instead)," explains Martin. "The macOS virtualization framework only supports running as a Type 2 hypervisor. So, to fix this, they'd have to re-design the entire thing to work as a Type 1 hypervisor."

"Basically, Apple decided to break the Arm spec by removing a mandatory feature, because they figured they'd never need to use that feature for macOS," he explains in his post. "And then it turned out that removing that feature made it much harder for existing OSes to mitigate this vulnerability."

The Register asked Apple whether a fix is planned prior to its next M1 release, said to be designated M1X and expected to power a future MacBook Pro update ... This moment of silence has been brought to you by Apple media relations.

Martin speculates the M1 system register at issue wasn't intended to be accessible at EL0 and thus would be considered silicon errata, a hardware design mistake.

"Apple has acknowledged the flaw, but I highly doubt it is fixed in the next silicon iteration; it's too quick for that," he told The Register. "Silicon design timelines are longer, and I don't think this is critical enough for Apple to want to spend any money/delays on pushing through fixes [at the] last minute where it's even possible."

In 2015, Microsoft senior engineer Dan Luu predicted a greater number of hardware bugs as chips become more complex and as production timelines get compressed due to competition. And in subsequent updates to his initial post, Luu said he had heard from industry sources who claim the departure of staff charged with chip validation has also degraded processor design quality. ®