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 …
“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.”
I never knew you could reduce the security risk of a bug by introducing and/or finding more bugs that leak the same data.
So how many bugs must be added to reduce a major security risk down to a minor security risk.
Only jesting I got what was meant.
"I never knew you could reduce the security risk of a bug by introducing and/or finding more bugs that leak the same data."
Same principle as in the UK we "only" have a few thousand CV19 infections each day, and we're all home-free, good to ignore the virus. Whereas in Australia you have 10 cases and get a 7 day lockdown.
Whilst Australia as a whole might be sparsely populated from a statistics point of view, it's also one of the highest urbanised countries in the World, with most of the population ~90% living in just a few cities and large towns, mainly in a rather narrow band around the coast.
It would be difficult to cut the UK off in the same way that Australia and New Zealand were able to.
What percentage of their food arrives on roll on roll off ferries or a tunnel ever few hours?
Sure we could have cut off all links, but then instead of dying of cv19 we'd died of starvation.
Not saying that our load of useless bloody morons aren't useless bloody morons, but what is possible in one place is not always possible in others.
I wonder whether any government anywhere managed a good response to all the different aspects dealing with a disaster like this.
There is a wide gulf between "close all the borders completely" and "actually implement a quarantine"
Yes, we'd still need food (and other) deliveries, but it is technically possible to switch trailers between trucks (not easy in terms of space, but technically possible) such that even the haulage doesn't need to present a significant ingress route.
What we actually did was open our borders completely, stop any checks at them and not bother with quarantine at all (and as far as I can tell we still don't have anything approaching quarantine).
We're an island, and should have been able to take advantage of that fact. We didn't - at all. We didn't even try to.
Given that I've been locked down since early March last year, that's 15 months so far.
OK - In the last 8 months I have left the house to exercise outdoors on my own - but the previous seven I left the house for three shielded blood testing clinics.
So yes - 5 months feels pretty short to me.
"the UK is rapidly approaching the point of herd immunity (induced by mass vaccination)"
Working on the basis of the "Indian variant" and Pfizer/Moderna's effectiveness, a vaccination rate of just under 90% *with both doses* is needed (one dose is 33% effective, 2 doses is ~87% effective).
The UK currently has just under 45% of the population having had both doses, so its' some way off.
Note that the numbers are more forgiving with the "Kent variant".
The formula is: Vaccination Level Required = (1− 1/Reproduction Rate [R]) / Vaccine Efficacy
https://www.bbc.co.uk/news/uk-57214596
(from Monday 24th May) reports that, for the Pfizer and Astrazeneca vaccines, "both vaccines were only 33% effective against the Indian variant three weeks after the first dose."
After 2 doses:
"The Pfizer vaccine was found to be 88% effective at stopping symptomatic disease from the Indian variant two weeks after the second dose, compared with 93% effectiveness against the Kent variant.
The AstraZeneca jab was 60% effective against the Indian variant, compared with 66% against the Kent variant."
Do you have a link to the later studies?
Using two vaccines and the most dangerous variant makes sense. If you protect enough for a less dangerous variant, it will not be enough for the most dangerous one. So do the math on the most dangerous one both from vaccine resistance and health outcomes unless one of these situations apply:
1. There are so many different dangerous variants that protecting against the most dangerous will still result in a large risk from other ones, in which case the numbers are even worse.
2. The plan is to prevent that most dangerous variant from getting in at all. If that succeeds, then you don't need to create immunity to it, but that opportunity has already passed for the UK.
Yeah but they don't need a vaccine. They've got a Donk.
Also, Mick Dundee runs the covid policies in Australia.
That's not a lockdown...that's a lockdown.
He's currently luring it out into the bush to take it on in his own territory.
It sounds stupid. But it's better than the Steve Irwin protocol of dangling meat in front of the virus and waiting it for it to strike before capturing it.
"Are you trying to say that vaccines won't work in Australia?"
No, of course they're not. Here's what they said:
"Difference is, the UK is rapidly approaching the point of herd immunity (induced by mass vaccination), whereas Australia is a sitting duck if it starts getting a foothold and running out of control."
The degree to which they're at or near herd immunity is disputed, but the point about Australia is that the UK has given about 63 million jabs and Australia has given about 4 million. If the virus were to spread a lot in Australia, its people would have a lot less protection due to vaccinations. Fortunately, Australia has already gotten quarantines working pretty well, so that probably won't happen, but the point about differential vaccination rates is valid.
Now that's a website non-design I can appreciate! No nonsense, no mobification with ginormous tiles that cover the whole screen and make you scroll down several pages to find information, no stupid java script, nothing!
I like the website already. Without reading any articles.... (I'll get to that later, security research counts as work ;) )
I went there a while back to read something – linked from some other page I was reading, though I don't recall what the source was, or why it was linking to Luu's "Static and dynamic languages literature review". My browser remembers I was there, though.
Just skimmed that article again, and I do appreciate how Luu picks at the methodological and data-hygiene issues in the papers he's reviewing, rather than simply accepting their claims (as many people seem to do, on the rare occasions that anyone cites any research at all).
Yeh they will be...
"The cross-talk isn't particularly fast... a bit more than 1MB/s."
So 8388609 bps?
1MB/s is fast enough to collect just about anything in less than 1 second. It's not like an attacker will be going for your daily blog channel video at 1MB/s (but they can now go for it's credentials numerous times over).
The bit-bang will never die!
MacOS processes can communicate with each other. iOS processes have official ways to communicate if they are created by the same development team (which usually means by the same company).
Now this vulnerability means two apps who want to communicate with each other can do so. Which means for damage you need two pieces of malware, created by different development teams, which somehow can achieve something bad if they cooperate which each individual couldn't do.
Can I keep my typewriter, or is that too prone to mechanical interference/tampering? (1951 or -52 Remington Rand Super-Riter; all levers and rods, no 'leccy. It's a heavy beast.)
P.S. Someone messed with the ink vial when you weren't looking -- the quill has been hacked!
A fuck'n Z80.
You may notice that zilog never made obscene claims of security. It never worried about it because the standardization of SHIT, which is what is manufactured by everyone today, hadn't happened.
New shit coming off the line and it's got fuck all holes all through it.
Keep buying it boys and girls and they will continue to make it just for you.
"Keep buying it boys and girls and they will continue to make it just for you."
Promises, promises... they said that about Lawn Darts and Quaaludes.
I also miss: mercury thermometers, "Ohio Blue Tip Matches", cars without computers, REAL Bicycle playing cards, ... wow, I could just keep going... and going... and going... (I miss that bunny too :-(
"The cross-talk isn't particularly fast – data transfer rate is said to be a bit more than 1MB/s."
By way of comparison, if I am to believe the all knowing internet, a T1 line from your local phone company will deliver about 1.544MB/s (and -- in the US -- cost about $200 a month). Two thirds of a T1 doesn't sound all that slow to me. And I suspect that many rural users here in North America still don't have connection speeds anywhere near that fast once they try to connect to the world at large.
If this channel is an actual security threat, I should think that the OS would have little trouble monitoring it and screaming should the bits involved start changing. But maybe I'm overlooking something. I often don't do all that well with complexity.
Good grief, and I thought internet was expensive here!
1MB/s = 8Mbit/s
The cheapest tarrif I could find (ok, didn't search all that much) was 16Mbit/s (down) and 2.4Mbit/s up at 35€. For upload speeds matching this one you need to pay 5€ more/month, resulting in 50Mbit down and 10Mbit/s up.
Or am I missing something?
Are you suggesting, sir, that I confused Mega-bits per second with Mega Bytes per second? You're correct. I did exactly that. T1 is 1.544 megaBITS per second. Not MegaBYTES per second.
And in response to a question down thread. Do people still use T1 in North America? I would imagine that some do. It's not like there are a lot of choices. Various forms of DSL may be able to deliver a fair number of MBPS at a reasonable cost -- if you are located within a few km of a phone company Central Office. Most rural users aren't. If you're further out and are beyond the reach of cable TV, your choices would seem to be whatever you can get from the phone company at probably extortionate prices, possibly wireless at probably extortionate pricing after you get by the dubiously honest advertising, high latency satellite. And Starlink once it gets going.
No, I was not thinking about that - I was really worried I'd mix them up though!
So... Yeah, thanks for educating me on the problems of rural Internet access. Where I'm living I can get 100Mbit/s, easily. Not sure about the cheapest prices for that, I don't even know what my provider charges for the current contract.
I should go and compare prices, I guess.
You're missing something. A T1 is a legacy connection, the telcos don't want to provide it. There's no up/down split, it's the same speed both directions. And it comes with various regulated service level obligations. Also, it's not 1.54MB/s, it's 1.54Mb/s. They're very uncommon now. The legacy 2Mb/s E1 is the rough equivalent in Europe.
The cheapest connection here is a $10/month 25Mb/s connection, not sure what the up speed is. Yes, that's a government subsidized low income price, but it's real and not uncommon.
In many places in the US, gigabit is available for about $100/month.
Prices and speeds vary wildly depending on where you live, cities tend to have better connectivity and lower prices, rural areas may have limited options.
The last T1 I personally dealt with was just shut down a few years ago, it was put in a few years before that because it's a regulated service that the telco had no choice but to install to the middle of nowhere, and having it installed accomplished the goal, it forced the telco to upgrade equipment and DSL became available not long after.
...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–2024
