back to article 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 …

Page:

        1. EnviableOne Silver badge

          Re: T1 - anyone?

          E1-> E3 -> EFM -> FTTP

    1. Mishak

      Re: T1 - anyone?

      Does anyone still use a T1? I guess it's a bit like business here (UK) that still use managed ethernet connections for £far-too-many a month when they can now get a 1000/1000 fibre connection for a lot less.

      1. iron Silver badge

        Re: T1 - anyone?

        Not everywhere can get fibre or even ADSL in the UK. A former employer of mine was still using ISDN in some remote offices a couple of years go because it was all that was available. The ISDN shutdown caused them lots of problems.

  1. Anonymous Coward
    Anonymous Coward

    "makes a bad situation a little bit worse"...

    ...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."

  2. anonymous boring coward Silver badge

    Bandwidth is typically expressed in bits/s. So Mb/s if it's megabits per second.

    1MB/s would be 8Mb/s.

    8Mb/s isn't a low bandwidth for "tapping". Not sure why anyone would claim that?

  3. Anonymous Coward
    Anonymous Coward

    Well, no.

    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.

    IMHO, those issues still pale into significance compared to the bugs in software..

    1. John Riddoch

      Re: Well, no.

      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.

      1. Michael Wojcik Silver badge

        Re: Well, no.

        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".)

  4. I Am Spartacus
    Holmes

    Te bug is real but can it be exploited

    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.

    1. Michael Wojcik Silver badge

      Re: Te bug is real but can it be exploited

      On an iMac or MacBook, unprivileged processes already have plenty of side channels.

      This is an interesting architectural mistake. It's hard to see how it introduces a plausible new threat.

      Martin makes all of these points on his site.

    2. gnasher729 Silver badge

      Re: Te bug is real but can it be exploited

      You need two malicious apps actually. An app cannot spy on another app with this, but receive data that is being sent intentionally.

  5. Jusme

    So...

    ...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.

    1. Julz Silver badge

      Re: So...

      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.

    2. Michael Wojcik Silver badge

      Re: So...

      As Martin explains, at length, on his site.

  6. You aint sin me, roit Silver badge
    Holmes

    Rule 0 of secure programming..

    "We'll never need that, might as well take it out" will always come back to bite you in the arse.

    1. Anonymous Coward
      Anonymous Coward

      Re: Rule 0 of secure programming..

      ""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.

      1. Version 1.0 Silver badge

        Re: Rule 0 of secure programming..

        "designers" are busy designing things to keep the folks running the sales department happy and meet their demands - maybe the sales folks thought this was a feature not a bug originally?

    2. runt row raggy

      Re: Rule 0 of secure programming..

      there are quite a number of security bugs caused by unnecessary things left in.

  7. Cynic_999 Silver badge

    Easy to protect against

    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.

    1. HildyJ Silver badge
      Boffin

      Re: Easy to protect against

      Sounds like DARPA's Morpheus chip design.

      https://www.extremetech.com/computing/323107-new-morpheus-cpu-design-defeats-hundreds-of-hackers-in-darpa-tests

    2. doublelayer Silver badge

      Re: Easy to protect against

      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.

      1. Cynic_999 Silver badge

        Re: Easy to protect against

        It would only take 2 or 3 instruction cycles to flip the bits. With a CPU running at 100's of MHz clock speeds, you could flip them at the rate of 10000 times per second with negligible performance degradation.

        1. Michael Wojcik Silver badge

          Re: Easy to protect against

          Still not difficult for the communicating apps to correct for this with modern codes.

          More importantly, it's irrelevant. There's no need to do this. Martin goes into this at length.

  8. ST Silver badge
    Devil

    So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

    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!

    1. ThomH Silver badge

      Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

      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.

      1. ST Silver badge
        FAIL

        Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

        > [ ... ] 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.

        1. ThomH Silver badge

          Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

          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.

          1. ST Silver badge
            Devil

            Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

            > 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.

            1. ThomH Silver badge

              Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

              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.

              1. ST Silver badge

                Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

                > 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.

            2. jtaylor Bronze badge

              Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

              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.

              1. ST Silver badge
                Facepalm

                Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

                > 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.

                1. jtaylor Bronze badge

                  Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

                  "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.

                  1. ST Silver badge

                    Re: So what happened to "Intel Sucks!!! Apple's M1 FTW!!!"

                    > 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.

  9. This post has been deleted by its author

  10. ThomH Silver badge

    It sounds like an easy hardware fix

    That is, for the M2 or M1X or whatever, with no obvious detriment — whereas the cost of mitigating e.g. Spectre seems to be performance.

    Although given what I imagine to be the lead times on CPU manufacture, maybe the 2022 processor is more likely?

  11. Sparkus Bronze badge

    Good thing the M1X

    is waiting in the wings to obsolete the first-gen M1 gear..........

  12. JBowler

    Hum, so now crackers can go full multi-process

    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.

    1. amanfromMars 1 Silver badge

      Re: Hum, so now crackers can go full multi-process against criminally negligent practices?

      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.

      1. Anonymous Coward
        Anonymous Coward

        Re: Hum, so now crackers can go full multi-process against criminally negligent practices?

        Why is it I always feel there is a hidden message in amanfromMars1's ramblings/nonsense?

        1. amanfromMars 1 Silver badge

          Re: Hum, so now crackers can go full multi-process against criminally negligent practices?

          Why is it I always feel there is a hidden message in amanfromMars1's ramblings/nonsense? .... Anonymous Coward

          Does it help you, AC, to know and realise they're more prognostications ‽ .

          1. Citizen of Nowhere

            Re: Hum, so now crackers can go full multi-process against criminally negligent practices?

            >Does it help you, AC, to know and realise they're more prognostications discombobulations

            FTFY AMFM ;-)

            1. amanfromMars 1 Silver badge

              Re: Hum, so now crackers can go full multi-process against criminally negligent practices?

              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.

    2. Michael Wojcik Silver badge

      Re: Hum, so now crackers can go full multi-process

      All of which is pointed out by Martin on his site.

  13. Anonymous Coward
    Anonymous Coward

    More importantly...

    ...is there a logo?

    1. Monty Cantsin

      Re: More importantly...

      There bloody well is!

      https://m1racles.com/

  14. gnasher729 Silver badge

    Worst case

    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.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021