Asahi Linux Dev Reveals 'M1RACLES' Flaw In Apple M1 (tomshardware.com) 47
AmiMoJo shares a report from Tom's Hardware: Asahi Linux developer Hector Martin has revealed a covert channel vulnerability in the Apple M1 chip that he dubbed M1RACLES, and in the process, he's gently criticized the way security flaws have started to be shared with the public. Martin's executive summary for M1RACLES sounds dire: "A flaw in the design of the Apple Silicon 'M1' chip allows any two applications running under an OS to covertly exchange data between them, without using memory, sockets, files, or any other normal operating system features. This works between processes running as different users and under different privilege levels, creating a covert channel for surreptitious data exchange. [...] The vulnerability is baked into Apple Silicon chips, and cannot be fixed without a new silicon revision."
He also noted that this was the result of an intentional decision on Apple's part. "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 explained. "And then it turned out that removing that feature made it much harder for existing OSes to mitigate this vulnerability." The company would have to make a change on the silicon level with its followup to the M1 to mitigate this flaw. But he also made it clear in the FAQ that Mac owners shouldn't be particularly worried about M1RACLES because that covert channel affects two bits. It can be expanded, and Martin said that transfer rates over 1 MB/s are possible "without much optimization," but any malicious apps that might take advantage of such methods would be far more likely to share information via other channels. Calling this a two-bit vulnerability would be both technically and linguistically correct. It's a real security flaw, sure, but it's unlikely to pose a real threat to Apple's customers.
He also noted that this was the result of an intentional decision on Apple's part. "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 explained. "And then it turned out that removing that feature made it much harder for existing OSes to mitigate this vulnerability." The company would have to make a change on the silicon level with its followup to the M1 to mitigate this flaw. But he also made it clear in the FAQ that Mac owners shouldn't be particularly worried about M1RACLES because that covert channel affects two bits. It can be expanded, and Martin said that transfer rates over 1 MB/s are possible "without much optimization," but any malicious apps that might take advantage of such methods would be far more likely to share information via other channels. Calling this a two-bit vulnerability would be both technically and linguistically correct. It's a real security flaw, sure, but it's unlikely to pose a real threat to Apple's customers.
Re: (Score:2)
Re: (Score:2)
Oh really? Intel does better? Apple was a part of the AIM alliance for years BTW.
In terms of covert channels, yes. There have been such things published and they have been addressed, along with others that have not been published.
A new silicon architecture is going to be full of as yet undiscovered vulnerabilities and without a team of security people who've been mired in the architecture for decades, they're going to be harder to catch before they make it into the silicon.
That's just how it is with multi billion transistor chips. Especially new clean-sheet designs.
Re: When software companies design chips... (Score:1)
You all suck (Score:5, Informative)
And you don’t even suck good.
From the website:
# So you're telling me I shouldn't worry?
Yes.
# What, really?
Really, nobody's going to actually find a nefarious use for this flaw in practical circumstances. Besides, there are already a million side channels you can use for cooperative cross-process communication (e.g. cache stuff), on every system. Covert channels can't leak data from uncooperative apps or systems.
[]
# So what's the point of this website?
Poking fun at how ridiculous infosec clickbait vulnerability reporting has become lately. Just because it has a flashy website or it makes the news doesn't mean you need to care.
Re: (Score:2)
It would be a lot harder to find data exfiltration from a plugin in a browser when it's moved to another program and logged to disk to be sent later.
Not on ARM (Score:2)
> Besides, there are already a million side channels you can use for cooperative cross-process communication (e.g. cache stuff), on every system.
The speculative execution and other performance-enhancing "special features" of Intel CPUs create those side channels on Intel processors. The ARM reference design offers a guarantee that such side channels don't exist. For example, caches are cleared as needed.
There is a tradeoff there. a CPU unconcerned about security can offer better performance, such as by l
Re: (Score:2)
> Just look at Straight-Line Speculation, it's a speculative cache side-channel
Which is precisely WHY ISB guarantees that there will be no speculative execution which could affect any caches.
Of course, your comment really isn't relevant to the guarantees about registers, but besides being irrelevant it's also wrong. ARM provides a guarantee that straight-line speculation will not occur in a cache-affecting way across barriers.
Re: (Score:2)
https://www.google.com/search?... [google.com]
Re:Not on ARM (Score:5, Interesting)
> The ARM reference design offers a guarantee that such side channels don't exist.
Nonsense. All modern CPUs have speculative execution side channels by nature. The only way to protect against these attacks is to change how we write software to insert speculation barriers in security-critical code paths.
The difference is that Intel doesn't just have speculative execution side channels, they had a pile of critical *security domain crossing* speculative execution side channels. All CPUs can leak data in speculation from your process into the side channel (which might be monitored by another process), but Intel has a pile of bugs which can leak data from *a completely different, innocent process*, or even the kernel (meltdown), or a VM hypervisor (L1TF). Those aren't inherent in CPU design, those are a result of what is clearly a major culture issue inside Intel.
> Spectre and Meltdown bed to differ.
Spectre and Meltdown are not covert channel issues. Spectre is a collection of speculative execution *side channel* issues, and Meltdown is a privilege domain crossing speculative execution *side channel* (the only one that hit other CPUs as well as Intel IIRC; other than Meltdown I think Intel has a monopoly on goofs this bad, e.g. L1TF). Covert channels are not the same thing as side channels, as they require cooperation from both sides.
Re: (Score:3)
>If you prove that side channels can't exist *even if the target process does exactly the wrong thing*, then you've proven that side channels will not affect any application.
Welcome to Yao garbled circuits and other variants of the same thing. The trouble is that it's costly (a handful of AES operations to execute a nand gate) but even full visibility of the internal state won't reveal what the plaintext is. This is an effective side channel defense.
Most side channel defenses are cheaper and not uncondit
Re: (Score:2)
This makes me wonder what their working definition of covert channel is. I understood that by definition a covert channel leaks data from an uncooperative system: indeed, from a system which is unaware of the data leak.
Re: (Score:2)
A covert channel allows one process to read from another process without the knowledge and permission of the OS.
That means a malicious process can read from the target process of the target does X, so the malicious process does Y.
In order to make security guarantees, we assume that some target process does X. That is, we assume that intentionally or accidentally the target does the dangerous thing.
For purposes of proving things, we pretend that the target process is cooperating intentionally. That's because
Re: (Score:2)
Right to repair didn't help SPECTRE, so no more a fuck-up than anyone else.
Re: (Score:2)
Well, once a CPU that fixed SPECTRE is available, you can replace socketed CPUs.
Since Apple devices with M1 SoCs are not designed to replace the CPU or even the SoC the only way to fix that security flaw is to replace the whole device.
That is a meaningful difference.
Re: (Score:2)
Really? I've been waiting 2, or is it 3, years for this mythical replacement CPU that I can just drop in. So, when do you think it will be available?
Sounds dire? Really? (Score:5, Insightful)
No it doesn't. Why would anybody ever want to exploit this? It sounds like a minor issue identified by a security researcher who thinks it's a minor issue, and written up to whip Apple haters on Slashdot into a froth.
Re:Sounds dire? Really? (Score:5, Funny)
Maybe we should retitle this as M1RACLEWHIP if that is it's purpose.
Re: (Score:1)
Maybe we should retitle this as M1RACLEWHIP if that is it's purpose.
OK, that was damn funny.
Re: (Score:2)
Surely you meant M1RACLEHWIP.
Signed,
Stewie.
Re: (Score:3)
Why it actually matters (Score:2)
It does matter, and it's not a critical flaw - yet.
First, we should clarify what an information leak *is*, what kind of flaw we're concerned about. What we're looking for is if a malicious process can read data from a target process illegitimately. What does illegitimately mean? In infosec, it means "without the blessing of the reference monitor (kernel) - without permission. We're concerned about a process getting access to data that it doesn't have permission to access.
To catch information leaks, ways tha
Re: (Score:2)
Neither the summary nor the linked page describes anything of the kind. From the discoverer's own fingers:
"A malicious pair of cooperating processes may build a robust channel out of this two-bit state"
Oooh, scary. You know how you can get two malicious processes to exchange data without the OS snooping on them? Make them one malicious process. Easier to get it on your computer too.
Re: (Score:2)
You're right, the summary doesn't explain infosec to you.
There are things that exist without being in this summary. :)
Re:Why it actually matters (Score:5, Insightful)
It really doesn't matter.
It's two bits in a register that Apple implemented poorly and macOS doesn't use properly that could fix it.
Here's the important bit: it's useless against a non-cooperative process. You see, to do the actual communications, it requires two processes to actually write and read that register. A normal process won't do that - it's a special instruction to access a special register not needed by applications.
So it's a register that can be read from and written to as a user mode process. But to use it, requires the processes in question to know about the register and to use it. If your application doesn't ever touch that register (why should it) then nothing happens. You can write an application that uses it as a data channel between instances of itself, but there's a chance another process can do the same and corrupt your data. And if you're really doing this, there are better methods to do IPC anyways.
After all, if you're going to go through the trouble of using this method, you're going to have to have to inject code into your target process, and really at that point, there are easier ways to exfiltrate the information than use this covert channel.
It's like saying if you want to leave a message for someone, to use the rock in my garden where you can hide a note and I wouldn't notice. It grants no access to my house - if you wanted to read an email on my computer, unless I have a good reason to use that rock, I probably wouldn't print out my email and hide it under the rock. If you wanted to read the email, you'd have to break into my house, read the email, and then communicate its contents. Sure, you could write it down and use the rock to hide the data, or you could just leave and tell whoever you need to the contents of the email directly rather than bother hiding it with the rock.
If you want to leak the browser secret key, once you get it, you probably can use a socket or other mechanism of IPC to communicate it.
It's basically a flaw that's present, but of no real significant value The author is basically using it to show you he can hype up a frenzy for what is effectively a nothingburger. Unlike Spectre and Meltdown attacks, which let you determine things with uncooperative processes, this flaw requires cooperation, and if you're trying to coerce it from an uncooperative process, once you've done it, there are better ways of exfiltration at that point.
Asserting it doesn't make it true (Score:2)
> your application doesn't ever touch that register (why should it) then nothing happens.
It's an undocumented register - you have no idea how the MacOS certificate handling, or Safari, or anything else, uses this register.
> It's useless against a non-cooperative process.
You've asserted that with no evidence whatsoever.
What we *know* is that it allows a malicious process to read data from any process that uses that register, without permission from the OS. You assume, without evidence, that the registe
Re: (Score:2)
No it doesn't. Why would anybody ever want to exploit this? It sounds like a minor issue identified by a security researcher who thinks it's a minor issue, and written up to whip Apple haters on Slashdot into a froth.
Extracting information from victim OSs in cloud VMs.
The M1 isn't running many cloud VMs these days, so no, it's not a big deal today.
Re: (Score:2)
Except the vulnerability isn't present in VM mode. A hypervisor is sufficient to negate the problem.
It's a rather obscure M1 implementation issue with a register that has to be properly virtualized, so the issue is only present in macOS because it has nothing in EL1 (hypervisor). Linux is actually safe because it has code that runs in EL1 (kvm) and EL2 (kernel mode).
Apple spin right there (Score:1)
"it's unlikely to pose a real threat to Apple's customers" = "here's only a small percentage of affected users"
Yeah, that is Apple spin right there. It's a lie.
Re: (Score:2)
For example it can break process isolation in browsers. Isolation is one of the major security tools used to protect browsers.
VMs are another common example. As ARM chips get more common in servers this kind of thing becomes more important.
Re: (Score:3)
If you actually bothered to read about the vulnerability you'd realise this has nothing to do with Apple haters, and rather its poking fun at the entire infosec community.
The posting was clever, the naming was clever, the release of the webpage for the exploit was clever. Never before has an exploit been so effective at weeding out who does and who doesn't bother to read up about it.
Congratulations on falling for the trap and showing to the world that you post about things you didn't even bother to read abo
Go read the page (Score:4, Interesting)
Apparently not only is this guy a talented hacker, he's pretty funny too.
So what's the real danger?
If you already have malware on your computer, that malware can communicate with other malware on your computer in an unexpected way.
Chances are it could communicate in plenty of expected ways anyway.
That doesn't sound too bad.
Honestly, I would expect advertising companies to try to abuse this kind of thing for cross-app tracking, more than criminals. Apple could catch them if they tried, though, for App Store apps (see below).
Wait. Oh no. Some game developer somewhere is going to try to use this as a synchronization primitive, aren't they. Please don't. The world has enough cursed code already. Don't do it. Stop it. Noo-oooo-ooo-ooo
(The 'noo' at the end is munged by me because pasting it in from his site flips Slashdot's absurd ascii-art trigger.)
Go on... (Score:2)
Some game developer somewhere is going to try to use this as a synchronization primitive
I like the sound of this hot illicit synchronization primitive, tell me more!
Wait, what? (Score:5, Insightful)
I mean, literally, wait .. what? On any multitasking computer, you can communicate between processes by timing how long your threads wait to do computation. How do you protect against this? And it doesn't even make much sense. You just have to make one process eat up CPU in a specific pattern (for example, factorize some big ass numbers) and then the second process just has to time how long its own computation takes. If it takes 1 second to compute 2+2, maybe the first process was operating. You can set that as bit 1. If it takes half a second, you can consider than a 0 .. and so on. Of course it is not super reliable, so you have to build in some error checking code and baselining. The bit rate of transfer will be slow, but it's good enough.
Re: (Score:3)
Re: (Score:3)
How do you protect against this?
You don't. Read up on the vulnerability. The entire purpose of this vulnerability is to demonstrate who falls for panic outrage and who actually bothers to read the notification.
You were trolled and you fell for it.
Re: (Score:3)
"completely useless" (Score:1)
Zero information (Score:2)
And MacOS devices are mostly single user systems. So if a user downloads malware, nobody but the user is affected. Very different from say a server that could run VMs for 20 different users, if malware _intentionally installed by one user_ could spy on 19 others.
Re: (Score:2)
There's plenty of information on it. It requires cooperative processes - the register isn't used by normal applications, but it provides two bits that can be tweaked by a user process.
If a couple of processes wanted to talk "quietly" they could signal each other using those bits. No normal process will touch the bits as
Re: (Score:2)
Of course there's no information in the summary - it's a test to see if you will RTFA [m1racles.com] (although, that may result in a lifetime ban from /. as anyone who RTFA before commenting is not following the social norms and is subject to being cancelled).
From what I can tell (yes, I RTFA, but hopefully I won't be banned), it allows two processes to "conspire" to communicate with each other covertly through two bits in a register shared by all processes even though they may be denied access to communicate through "tra