Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Apple Hardware

MIT Researchers Uncover 'Unpatchable' Flaw in Apple M1 Chips (techcrunch.com) 56

Apple's M1 chips have an "unpatchable" hardware vulnerability that could allow attackers to break through its last line of security defenses, MIT researchers have discovered. TechCrunch reports: The vulnerability lies in a hardware-level security mechanism utilized in Apple M1 chips called pointer authentication codes, or PAC. This feature makes it much harder for an attacker to inject malicious code into a device's memory and provides a level of defense against buffer overflow exploits, a type of attack that forces memory to spill out to other locations on the chip. Researchers from MIT's Computer Science and Artificial Intelligence Laboratory, however, have created a novel hardware attack, which combines memory corruption and speculative execution attacks to sidestep the security feature. The attack shows that pointer authentication can be defeated without leaving a trace, and as it utilizes a hardware mechanism, no software patch can fix it.

The attack, appropriately called "Pacman," works by "guessing" a pointer authentication code (PAC), a cryptographic signature that confirms that an app hasn't been maliciously altered. This is done using speculative execution -- a technique used by modern computer processors to speed up performance by speculatively guessing various lines of computation -- to leak PAC verification results, while a hardware side-channel reveals whether or not the guess was correct. What's more, since there are only so many possible values for the PAC, the researchers found that it's possible to try them all to find the right one.

This discussion has been archived. No new comments can be posted.

MIT Researchers Uncover 'Unpatchable' Flaw in Apple M1 Chips

Comments Filter:
  • Code Read Only. (Score:5, Interesting)

    by splutty ( 43475 ) on Saturday June 11, 2022 @08:05AM (#62611352)

    This is something that IBM Mainframes have had since they existed, pretty much.

    A "Code" block is read only. Nothing can write to that except the initial loader, after which it is set to read only in a hardware layer.

    You can do stack overflows all you want, but you're never going to be able to modify that code from within a program (or another program for that matter, since it's invisible from that other program to begin with).

    • That makes it harder to do JIT for JavaScript, etc. You can design a processor to make it more secure, sometimes you must make a decision between performance and security. For Apple many of these decisions were already made by ARM and can't be altered without creating incompatibilities and agreement violations of the licensed architecture.

      A slow and steady processor that eliminates many common optimizations could be made immune to all known side channel attacks. The lack of prediction may prevent the cache

      • Re:Code Read Only. (Score:5, Insightful)

        by The Evil Atheist ( 2484676 ) on Saturday June 11, 2022 @10:05AM (#62611550)

        That makes it harder to do JIT for JavaScript, etc

        Fantastic outcome.

        • Horrible outcome. I like my interactive Lisp environments, thank you very much.
          • You can have interactive Lisp environments without JIT.

            Surely, Lisp is so powerful that it can overcome physics, with its infinitude of features and capabilities.
            • The whole point of Lisp is interactivity and reasonable performance. Not sure how you get reasonable performance without compilation and interactivity without compilation that integrates new machine code into a running process.
              • But surely all those amazing features of Lisp means that it can do things faster magically without having to resort to compilation.
                • What's wrong with compilation? All serious programming language implementations are compilers.
                  • Nothing. I myself prefer AOT compiled languages.

                    But Lisp advertizes itself as so powerful that its homoiconicity etc etc should be able to blow compiled programs out of the park without resorting to JIT cheats.
                    • Lisp advertizes itself as so powerful that its homoiconicity etc etc should be able to blow compiled programs out of the park without resorting to JIT cheats.

                      Your statement makes no sense. First of all, I've never seen anyone even make that claim. Second, having features X, Y, and Z without compilation is strictly worse than having the same features X, Y, and Z *with* compilation on top of them. BTW what even are "JIT cheats"?

                    • BTW all major implementations of Common Lisp used in practice are AOT-compiled: Allegro, Lispworks, CCL, SBCL. The upcoming SICL and Clasp are no exception. They just don't put additional artificial limitations on themselves the way that for example C++ does (such as, if you have already existing data in memory, it can no longer change shape).
    • That is a 360 green card (programmer's architectural model) perspective that is too narrow to tell modern truth. Many of these recent attacks target the memory system (DRAM refresh, cache, multi-core cache consistency). Even the limited pipelining in 360/91 would give behaviors outside the common green card understanding, with imprecise exceptions.
      • by splutty ( 43475 )

        But that's kind of the point, isn't it? Modern CPU architecture are pretty much designed for performance over anything else, and security seems to be very low on the priority list.

        Whereas the 360/370/390 series were very much designed to be as secure and segmented as possible.

        My experience is mostly in assembly on those systems, and the finegrained control you could exert over things (primarily wrote RACF related stuff, so my experience is very coloured by that, admittedly), was always something that made m

    • Re:Code Read Only. (Score:5, Informative)

      by tlhIngan ( 30335 ) <slashdot&worf,net> on Saturday June 11, 2022 @09:23AM (#62611502)

      This is something that IBM Mainframes have had since they existed, pretty much.

      A "Code" block is read only. Nothing can write to that except the initial loader, after which it is set to read only in a hardware layer.

      You can do stack overflows all you want, but you're never going to be able to modify that code from within a program (or another program for that matter, since it's invisible from that other program to begin with).

      These days, it's known as W^X, or write-xor-execute. That is, a block of memory can be writable, or executable, but not both. You apply this liberally - on the code section (which is typically read only anyways because of the way modern OSes do caching - code text is readonly and pageable so it can be discarded if memory is needed, and then just pulled back from the disk file when eeded). The stack heap and data memory are marked W^X so the processor generates a fault if it tries to execute in those regions.

      But that doesn't stop all attacks - and it's so common these days that exploits never generally use a direct buffer overflow to end up running arbitrary code.

      In stead, a technique called Return-Oriented-Programming or ROP is used, and what happens is you overflow the stack, but instead of putting executable code there (which can't run as W^X makes it generate a fault), you basically put on a bunch of return addresses so when the processor pops an address off the stack, that address contains a function call to do something the programmer wanted, and the stack is set up with call parameters as needed. So basically the processor returning from a function is treated as stack-indirect jump where the jump address is given by the contents of memory pointed to by the stack pointer.

      That's why we have ASLR - return oriented programming requires you to know where the functions you want to call are in memory, so ASLR makes those calls harder to make if you don't know where the functions you want to call are.

      • by splutty ( 43475 )

        Thanks for that. Wasn't aware of some of what you're saying. I'm rather behind the times :)

    • If I know the read only code and I can hack the stack I can search the read only code for the instructions that I want that are just before a return instruction. I then "compile" my code so that my program is a bunch of stack variables and return pointers.
  • If you have the hardware with you and can stick traces on there why bother with the other shit?

    And that's one pointer. There are millions of pointers active.

    It's annoying that these kinds of vulnerabilities are reported. They are irrelevant to everyone except the NSA.

    • If you have the hardware with you and can stick traces on there why bother with the other shit?

      It's almost as if you missed the line where it says "since there are only so many possible values for the PAC, the researchers found that it's possible to try them all to find the right one."

      A PAC might be only 40 bits and it's no big deal to brute force that these days.

    • It's annoying that these kinds of vulnerabilities are reported. They are irrelevant to everyone except the NSA.

      Or, if you look at the bright side, they're publicizing a method that might enable you to hack your computer's hardware in a way that might allow you to defeat annoying DRM used against you.

      If an exploit requires deliberate, permanent hardware modification, it's unlikely to be useful against your own personal interests unless you're someone who has state-sponsored espionage agencies teaming up against you (in which case you're probably fucked one way or another, anyway, unless you're the President of the US

      • Or you could just be an employee of a mining, utility, medical, infrastructure, bank, car, defence, cleaning, airline, it, software, or accounting company or government agency with access to any piece of innocuous but ultimately useful information. That would pretty much cover a big chunk of the population.
  • by Wolfier ( 94144 ) on Saturday June 11, 2022 @08:20AM (#62611368)
    OK, so it's not a remote attack and you need to set up sensors near the machine to exploit. Next.
    • Doesn't necessarily mean you have to have Hardware. Side Channel exploits in Hardware can be discovered by software.

      Sounds like Pac leaks via some other hardware mechanism (power usage, RFI, timing hiccups)

    • OK, so it's not a remote attack and you need to set up sensors near the machine to exploit.

      Next.

      Try reading the last line of the summary. It's a long way down, I know...

  • Last month we discussed an unpatchable, inherent flaw in Apple's processors [slashdot.org] which "leaks data at rest [prefetchers.info]". (Which, I might add, would once have been linked as a related story... in the pre-B!zX days that is.) Now we've got yet another failure. Apple fans have gushed and gushed about the performance of these chips but they're getting their comeuppance now in exactly the same way as Intel's followers, where the performance advantage goes away when security is taken into account.

    It will be interesting to see if A

    • by keltor ( 99721 ) *
      You are making an assumption that they need to patch the issue.
      • You are making an assumption that they need to patch the issue.

        I see you didn't read the second paragraph of my comment, probably because you were triggered by the first one. You really need to segregate these brands from your identity. It's not healthy to identify yourself with a publicly traded corporation that could not possibly give one fuck about you, because corporations don't have hearts, minds, souls... or consciences.

        Apple is going to have to mitigate at least the Augury flaw discovered in May, because it has been demonstrated that it can be practically exploi

    • I bought into the ecosystem (I own 2 M1* machines, now) knowing full well the sidechannel guys were going to have a hayday with them. I'm really ok with that.
      It's hubris or koolaid intoxication to think that any processor is immune to such things.

      The previous one worse than this.
      This just means arm64e binaries may as well be arm64, which is fine.

      As for mitigation? No way in hell.
      If the PAC is broken, arm64e mach type is pointless until it's fixed in a future silicon. Linux doesn't really apply much h
      • "As for mitigation? No way in hell. If the PAC is broken, arm64e mach type is pointless until it's fixed in a future silicon."

        That is one of the authors recommendations in Part 9. Dont allow spec exec for Pointer authentication. Duh. This could help Qualcomm et al get a better price on arm from the Brits, although an exploit of this seems very unlikely. Also from the paper.

        ""As part of our reverse engineering effort, we designed PacmanOS, a bare-metal execution environment written entirely in Rust th
    • by EvilSS ( 557649 )
      Apparently not Apple Exclusive: https://hardware.slashdot.org/... [slashdot.org]
  • by enriquevagu ( 1026480 ) on Saturday June 11, 2022 @08:34AM (#62611394)

    The original authors have documented their attack in this website [pacmanattack.com], and it has been accepted for ISCA'22 [iscaconf.org]. It will be presented in 10 days, and the actual paper is already available here [pacmanattack.com].

    The work does not attack apple M1; the work attacks a security mechanism in ARM, introduced in ARMv8.3. They have employed the Apple M1 processor, which employs ARMv8, but it is very likely that many other ARMv8-based processors will have the same limitation.

    The attack does not allow you to compromise a system by itself. ARM Pointer Authenticator Codes is a security mechanism that prevents exploiting some memory corruption vulnerabilities. With this new attack, it is again possible to exploit code that has vulnerabilities. It is the memory corruption vulnerability in the code the one that will allow attackers to compromise the system, PAC was an additional protection to prevent it.

    • by enriquevagu ( 1026480 ) on Saturday June 11, 2022 @08:48AM (#62611426)

      After reading other comments, some additional clarifications:

      First, this does not seem to be a "hardware attack". It is a software attack; it employs a micro-architectural side-channel attack to exploit a hardware mechanism (PAC). To perform this attack, it is required to have access to high-resolution timers. Second, as it is not a hardware attack, there is no need to have physical access to the system of install physical sensors of any type.

  • Then why did MIT remove the paper - or was it flawed?

    Not Found
    The requested URL /weontaek/pubs/PACMAN_ISCA22.pdf was not found on this server.
    Apache/2.4.7 (Ubuntu) Server at people.csail.mit.edu Port 80
  • I submitted this exact article with this exact summary text yesterday afternoon.

    The article goes on to say that these vulnerabilities are likely present in *all* ARM architectures.

    In a proof of concept, the researchers demonstrated that the attack even works against the kernel â" the software core of a deviceâ(TM)s operating system â" which has âoemassive implications for future security work on all ARM systems with pointer authentication enabled,â says Joseph Ravichandran, a PhD student at MIT CSAIL and co-lead author of the research paper.

    âoeIf not mitigated, our attack will affect the majority of mobile devices, and likely even desktop devices in the coming years,â MIT said in the research paper.

    • The article goes on to say that these vulnerabilities are likely present in *all* ARM architectures.

      This vulnerability is a flaw in a security measure which is intended to protect against a known vulnerability. So while the underlying vulnerability is likely present in all ARM architectures, Apple's failure to craft a successful mitigation is what's at issue here.

  • So this "flaw" is that a security mechanism is not perfect? Welcome to the real world.

  • Seems this PACMAN has their own advertising staff, jeez louise. This is their link from BleepingComputer.
    https://pacmanattack.com/ [pacmanattack.com]
  • CPU: Doctor, I have a critical vulnerability when I do this.
    Doctor of CS: Well don't do that.

    A twist on an old joke but it's actually precisely how you address non-patchable hardware issues like this. Spectre vulnerabilities were addressed by modifying OS kernels and compilers and redeploying everything. I suspect Apple has been working on a similar approach to prevent this from being possible while publicly downplaying the fact that this is a full compromise ("If only run authorized software, there is no problem!").

  • by Gravis Zero ( 934156 ) on Saturday June 11, 2022 @09:16AM (#62611498)

    Original MIT article: https://news.mit.edu/2022/rese... [mit.edu]
    The paper: https://pacmanattack.com/paper... [pacmanattack.com]
    Site about vuln: https://pacmanattack.com/ [pacmanattack.com]

    Seriously, TechCrunch is crap compared to these.

  • by Bruce66423 ( 1678196 ) on Saturday June 11, 2022 @09:46AM (#62611526)

    Wonderful flaw, carefully implemented, and now spotted. Oh well...

    I THINK I'm being paranoid ;)

  • Buffer overflows are a sign of incompetent coding and incompetent testing. (No, they are _not_ a sign of a bad programmin language, stop pushing that nonsense.) Maybe we should make sure people writing code know what they are doing instead of hiring cheaper and cheaper "coders" that write worse and worse code?

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...