Unfixable Apple M1 chip bug enables cross-process chatter, breaking OS security model 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 …
...could easily apply to the article itself:
From the FAQ on m1racles.com :
"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."
Yes and no... software bugs are more widespread and usually easier to exploit, but they're also considerably easier to patch over. Hardware bugs can be difficult to impossible to work around; I don't think there's a comprehensive set of fixes for all the SPECTRE & MELTDOWN issues yet, at least not without obliterating CPU performance.
There's no sign that a "comprehensive" fix for microarchitectural side channels will ever come. For one thing, researchers keep finding new ones.
Generating and discarding information has physical consequences. It's very difficult to mask all signals from those consequences.
(By the way, I quite like OP's "pale into significance".)
If I understand this correctly, two co-operating processes can communicated over a hardware side-channel. The speed that this happens at is, frankly, irrelevant The fact that it happens is the real worry.
However, if this is on IoS you have to either get the app from the app store, or jail break the iPhone/iPad. If you jailbreak it then you're very much on your own. If its apps from the app store then you are downloading compromised applications. If you have a compromised app then I am not sure whether the CPU bug matters at all, given that you have, however inadvertently, downloaded something nefarious.
On an iMac or MacBook (and I am in the market for a new M1 MacBook, so this does matter!) then the problem is more serious. You can download apps from anywhere.
There is no saving grace (not even, there are so many other points of intrusion that this doesn't matter). Nor that similar problems plague Intel and AMD.
...two (or more) processes that are running code I control can communicate with each other, but because this is done through an inefficient/unintended/undocumented feature it somehow "breaks the OS security model"?
I'm not big on MacOS, but I would assume it provides shared store/sockets/pipes, and possibly other methods of proper IPC, between co-operating processes?
Yes, malware could use it as an unofficial/untracked channel, but at the point where you have code doing that you've got much bigger problems already.
Indeed. Not to mention calling home for instructions and other less obvious channels.
If a process or processes are running on your system intent on mischief there really isn't much you can do to stop them. In fact, in my experience many processes seem to do mischief without any malign intent by their creators.
""We'll never need that, might as well take it out" will always come back to bite you in the arse."
Especially when, as seems to have happened here, the architectural geniuses doing the decision making didn't understand why the design was what it originally was.
All that is required is to install a separate background application that is always running and changes the relevant bits of that register reasonably often. This will alter the register in between the times the two communicating applications use it, so destroying their pseudo-clock and resulting in corrupt data. Such an application would be very small (just a few bytes of code), easy to write and have insignificant impact on system performance.
It depends how often you want to thrash those bits. If you flip them randomly every 0.5 seconds, that means the channel is corrupted once in every 512 KB transferred. If the applications use packets and checksum them, they can figure that out and retransmit. You would probably have to flip them a lot more often to block the channel, but then you might see some performance degradation.
Not so sure anymore?
Here's a few excuses to try out, see if they work:
- Yeah, but it can't be exploited.
- Yeah, but even if it's exploitable no-one has yet.
- Yeah, but transfer rate. Nobody wants to exfiltrate passwords or keys at 1MB/sec.
- Yeah, but it's Apple! Apple is flawless and magical!
The same thing that happened to "Wow, Tom H is the coolest! He's the king of the world!" and all other statements that nobody has ever actually uttered.
Knowing one of the specific flaws in the M1 doesn't change the general parameters, any more than knowing one (or many) of the specific flaws in macOS.
> [ ... ] and all other statements that nobody has ever actually uttered.
Oooooh, really?
I clearly remember many commentards here swooning over how amazing the M1 chip was, how it should be in servers and not just on laptops, how super-fantastic it will be now that we have a pointless Linux port to it, with a user-installed base of 9, and how the M1 doesn't suffer from all of Intel's leakage and exfiltration problems. Because Amazing and Secure M1 is. Woo-Hoo!
Yeah, turns out they swooned too soon. What a surprise.
Spin it away, mate. I'm aiming for at least five furious replies from you.
Oh, yeah, and it's a totally easy fix in the M2. You already know that.
I clearly remember many commentards here swooning over how ... the M1 doesn't suffer from all of Intel's leakage and exfiltration problems. Because Amazing and Secure M1 is. Woo-Hoo!
This is neither a leakage nor an exfiltration problem (and it doesn't fit the other things I edited out either). I think the original researcher has been pretty thorough in his write-up:
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.
...
If this bug doesn't matter, why did you go through all the trouble of putting this site and the demo together?
Honestly, I just wanted to play Bad Apple!! over an M1 vulnerability. You have to admit that's kind of cool.
So playing the playground brands-as-tribes game isn't really valid here; it's leaping on a single idiotic error of Apple's and pretending that it's both idiotic and consequential. By luck it isn't. But nothing about this vulnerability makes Intel look good. Especially not in a world with AMD.
> Really, nobody's going to actually find a nefarious use for this flaw in practical circumstances.
Yaaaaaaaaaaaaaaaaaaaa. Right. Nobody's gonna do that. Because people are nice and they don't do this kind of stuff. And because no-one has any interest in exploiting this vulnerability. And because AppStore.
"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 Ashai Linux, in his vulnerability disclosure. "This allows the processes to exchange an arbitrary amount of data, bound only by CPU overhead."
You seem to believe that those interested in exploiting this vulnerability are all just a bunch of amateur boobs.
From the looks of it, this looks worse than Intel's Spectre. At least Spectre can be mitigated by disabling SpecEx - at a significant performance cost. This M1 hole can't be mitigated.
Pull the other one, and leave Intel out of it. This has nothing to do with Intel.
Mandatory Disclaimer: I don't work at Intel.
The disclosing security researcher said:
Really, nobody's going to actually find a nefarious use for this flaw in practical circumstances.
You said:
Yaaaaaaaaaaaaaaaaaaaa. Right.
I think he's available on Twitter if you really want to argue with him.
> I think he's available on Twitter if you really want to argue with him.
I don't need to argue with the researcher. And I don't have a Twitter account.
What the Linux M1 port guy described about the vulnerability is sufficient and perfectly clear. And I am quite familiar with the AArch64 ISA to understand exactly what this vulnerability means in real life terms.
Anyone who claims that it doesn't matter, or that it can't be exploited, is full of BS.
Nobody's gonna do that. Because people are nice and they don't do this kind of stuff.
This exploit doesn't obviously offer anything that can't already be accomplished better using the methods normally available to userland processes.
You seem to believe that those interested in exploiting this vulnerability are all just a bunch of amateur boobs.
It has not yet been demonstrated that this exploit has practical use.
From the looks of it, this looks worse than Intel's Spectre.
Spectre permits access to protected kernel memory. It can be used to escape a jail or VM. This exploit permits passing messages between userland processes where the OS already provides easy and effective ways to do so.
leave Intel out of it.
Hey, that was you.
> This exploit doesn't obviously offer anything that can't already be accomplished better using the methods normally available to userland processes.
Really?
Can (hypothetical) userland pid_t 1538 read from some other (hypothetical) userland pid_t 7996's address space?
I'll answer that for you: no it can't and it shouldn't. That's what privilege separation enforces.
What M1's vulnerability does is: it tosses away this separation. Why don't you read the description of the vulnerability in the article, again:
"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 Ashai Linux, in his vulnerability disclosure. "This allows the processes to exchange an arbitrary amount of data, bound only by CPU overhead."
Is this so difficult to understand?
Separate and disjoint processes that should normally share nothing can now read each other's data.
That is exactly what Spectre was all about - albeit by a less idiotic mechanism - and everyone freaked out about Spectre. But hey, when Apple does a much bigger idiocy of the same category, it's cool. Not problem, nothing to see, move along, everything's fine.
> Hey, that was you.
No that wasn't me. That was the ThomH fanboi: But nothing about this vulnerability makes Intel look good. Especially not in a world with AMD.
"Why don't you read the description of the vulnerability in the article, again: "A malicious pair of cooperating processes may build a robust channel..." Is this so difficult to understand?."
I wouldn't think so. It's all there in the first 6 words.
"Separate and disjoint processes that should normally share nothing can now read each other's data."
Possibly, but not because of this exploit. You're not distinguishing between "A malicious pair of cooperating processes" cooperatively passing data (as you would through IPC, temp file, etc) and a single hostile process reading the soul of the kernel.
"leave Intel out of it." "No that wasn't me."
It's literally the fifth word in the title you chose for this thread. I'm starting to smell troll.
> Possibly, but not because of this exploit. You're not distinguishing between "A malicious pair of cooperating processes" cooperatively passing data (as you would through IPC, temp file, etc) and a single hostile process reading the soul of the kernel.
Either:
- You are too ignorant to understand what you just wrote.
- You are too stupid to understand this vulnerability, or how privilege and address space separation work.
- You are arguing in bad faith.
Either way, you are a waste of my time.
This post has been deleted by its author
Yeah! Rather than crudely drop their code into one single process now they can multi-task the cracker job across many processes communicating via the newly discovered communication channel. Of course they only need to do this if they can't touch anything else in the system, like the file system, or the disk, or create named IP sockets or send messages to the innernet, or the clipboard or the, what's it called, dbus thingy, or udev or the screen outside their own window, if, indeed, they have one.
Or they could just say, "Whatever" and simply create a single multi-threaded process. Oops, time for a CVE. Crackers can create multiple threads!!!! AAARGH, we'll all dead.
Yeah! Rather than crudely drop their code into one single process now they can multi-task the cracker job across many processes communicating via the newly discovered communication channel. ...... JBowler
Yes, it's typical Apple. Another novel innovative feature introduced and floated out into the market place space either missed or destined to be popularly dissed by competitors because there is increased deep advantage delivered with familiar use covertly and clandestinely into intelligence flows and information mainstreams.
Now that would describe and introduce much more a "hot" chip than "floored" processor ....... and gravely to be regarded by competitors unequipped with the utility and facility of its abilities.
Such a realisation/spin on discoveries has one wondering what improvements and refinements will be available with future iterations in the likes of an M1X, ad infinitum to M1XSSXXXX ..... with more than just a dedicated few always ready and eager to purchase and beta test hidden crown jewelled Fabergé easter egged models for that great deal extra supplied not conveniently catered for by anyone else anywhere else ...... until or unless the competition ups its game and gets its acts together to improve on the advantage rather than battle against it with wilful and ineffective opposition.
FTFY AMFM ;-) ..... Citizen of Nowhere
:-) Methinks more you've got yourself into a fix and a bind, because you are not understanding, Citizen of Nowhere.
Can we initially for now agree at least upon disambiguations until such times as everything becomes evidently clearer? Such can move things on a great deal better and considerably faster in strange territory never experienced alive before.
Here’s the worst case that I can think of: You have a server with multiple users, all properly separated, with no internet connection, so even malware couldn’t spill any secrets.
One of the users is malicious and _has_ an internet connection. The other users run apps that are not protected from each other. If I can install malware on one user’s account, that malware can transmit any data to the malicious user, and the malicious user can send it to a server.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
