[HN Gopher] MIT researchers uncover 'unpatchable' flaw in Apple ...
___________________________________________________________________
MIT researchers uncover 'unpatchable' flaw in Apple M1 chips
Author : markus_zhang
Score : 372 points
Date : 2022-06-10 13:03 UTC (9 hours ago)
(HTM) web link (techcrunch.com)
(TXT) w3m dump (techcrunch.com)
| macinjosh wrote:
| This is the second hardware security flaw in the M1. Was this
| known to Apple in time for M2?
| gjsman-1000 wrote:
| Second security flaw that is nowhere near as significant as
| Meltdown/Spectre and their endless derivatives. Still a good
| showing.
| tcmart14 wrote:
| Just taking a stab in the dark, I guess we won't know until the
| M2s are out. On the site by the researchers, they have been in
| talks with Apple since 2021 about this. To there may be a fix
| in the M2. However, we won't know for sure until the M2s are
| out in the public and in the hands of researchers. I don't know
| what the turn around time is for silicon design on an
| Engineer's desk to TSMC to being placed in a board on a Mac. It
| could be that it was too late in 2021 to make a change.
| ben7799 wrote:
| The author is here and ought to make it all clear but if you
| google the title of the article you can download the paper
| already despite everyone being coy about it and the ACM not
| having published it yet. It's kind of ridiculous it's getting
| this kind of press before the paper is officially published and
| available. If the paper was published and security experts were
| allowed to analyze it before the tech press went nuts the stories
| would probably have a different tone.
|
| This is interesting theoretically but the amount of access
| required is pretty high, this is hardly an exploitable zero day.
|
| Having read the paper, in a nutshell it requires:
|
| - Login to the Mac in question
|
| - Ability to install a custom kext to make the PACMAN Gadget
| work. The exploit requires access to undocumented registers on
| the M1 that are apparently not accessible from user space, but
| this is a bit unclear.
|
| - Also need an exploitable kernel buffer overflow against Mac OS
| (they made a custom kext with a buffer overflow)
|
| - Run the bufferflow + Pacman Gadget together to do the final
| elevation
|
| If someone can find a way to do this without installing kexts
| then it becomes way more serious. As is it certainly is a super
| interesting paper and presents a bunch of work for chip
| designers.
| jprx wrote:
| Hi! I think I can clear a few things up here.
|
| Our goal is to demonstrate that we can learn the PAC for a
| kernel pointer from userspace. Just demonstrating that this is
| even possible is a big step in understanding of how mitigations
| like pointer authentication can be thought of in the spectre
| era.
|
| We do not aim to be a zero day, but instead aim to be a way of
| thinking about attacks/ an attack methodology.
|
| The timer used in the attack does not require a kext (we just
| use the kext for doing reverse engineering) but the attack
| itself never uses the kext timer. All of the attack logic lives
| in userspace.
|
| Provided the attacker finds a suitable PACMAN Gadget in the
| kernel (and the requisite memory corruption bug), they can
| conduct our entire attack from userspace with our multithread
| timer. You are correct that the PACMAN Gadget we demonstrate in
| the paper does live in a kext we created, however, we believe
| PACMAN Gadgets are readily available for a determined attacker
| (our static analysis tool found 55,159 potential spots that
| could be turned into PACMAN Gadgets inside the 12.2.1 kernel).
|
| Our paper is available at our website:
| https://pacmanattack.com/paper.pdf
| ben7799 wrote:
| Something definitely went wrong here though that more
| guidance was not provided to the tech journalists.
|
| Most of the mainstream articles make it seem like they a) did
| not read the paper b) are incapable of understanding the
| paper c) were not provided any guidance about what any of
| this actually means in the real world.
|
| Which is all scary as the paper is well written and very
| accessible IMO.
| marcosdumay wrote:
| a) did not read the paper
|
| Yeah, that's a given. Journalists do not have time for
| optional tasks.
|
| b) are incapable of understanding the paper
|
| That's a safe bet.
|
| c) were not provided any guidance
|
| Asking for guidance or clarifications is another one of
| those optional tasks.
| bee_rider wrote:
| Based on the article, I think the journalist basically
| understands the situation (and if they don't, they should
| investigate further, that's the job). The headline is just
| intentionally over-dramatic to get clicks. This shouldn't
| be treated as a good-faith error, more guidance isn't
| required and wouldn't help.
| jazzyjackson wrote:
| d) were given about 90 minutes to write the article
| azinman2 wrote:
| Welcome to tech journalism.
| opheliate wrote:
| Just tech journalism? :) https://en.wikipedia.org/wiki/Mi
| chael_Crichton#GellMannAmnes...
| sirspacey wrote:
| Welcome to journalism.
| rTX5CMRXIfFG wrote:
| It's not just a problem with journalism but with humans
| in general. People are more imprecise with their
| comprehension of things than they are willing to admit.
| SantalBlush wrote:
| Thank you. Even here on HN, plenty of folks will comment
| on all kinds of research they know little about.
| thibauts wrote:
| Welcome to advertising driven journalism.
| TrevorJ wrote:
| >Most of the mainstream articles make it seem like they a)
| did not read the paper b) are incapable of understanding
| the paper
|
| This seems pretty par for the course in terms of
| science/tech journalism to be honest.
| KennyBlanken wrote:
| You didn't clear up anything about _publicizing this heavily
| in mainstream press before it 's been reviewed by your
| peers._
| nostrebored wrote:
| What are you hoping for here? Look at the facts as written.
| MBCook wrote:
| Once you can get someone to install your kext aren't you
| basically at game over anyway?
|
| Or do they have strong limits as well?
| throwaway290 wrote:
| Installing a kext is a password prompt away, I believe, so all
| that's needed technically seems to be "install something not
| reviewed by Apple, fill in a genuine OS password prompt when
| asked, and run it" which strikes me as a very common scenario.
| bhj wrote:
| Enabling 3rd-party extensions is much more involved on AS
| Macs: https://support.apple.com/guide/mac-help/change-
| security-set...
|
| Then the extension needs to be allowed in System Preferences
| > Security (this step has been required on Intel Macs too)
| jprx wrote:
| Additionally, if can find a way to trick a user into
| installing a malicious kext, why even bother with PACMAN?
| You already have arbitrary kernel code execution!
| throwaway290 wrote:
| Perhaps the kext with the overflow may not necessarily
| look malicious? It can serve as an actually useful kext
| and pass review.
| woliveirajr wrote:
| > "PACMAN is an exploitation technique- on its own it cannot
| compromise your system. While the hardware mechanisms used by
| PACMAN cannot be patched with software features, memory
| corruption bugs can be."
|
| reading the "official" site of the Researchers gives more clues
| than the headline of the article.
| gjsman-1000 wrote:
| Also important to mention that PAC is a new ARMv8.2 feature and
| previous versions of ARM have no PAC system at all. The only
| ARM chips with PAC are from Apple and AWS Graviton3 - any other
| chip has no hardware protections against this.
|
| So ultimately, right now, it's just downgrading a very new
| protection to as if it didn't exist, which is exactly how 98%
| of ARM chips in the world operate right now. Not great, not
| terrible, A for effort, was worth a shot, speculative execution
| breaks everything.
| adrian_b wrote:
| Besides the Apple CPUs and Graviton 3 (Armv8.4-A), the cores
| introduced by ARM in 2021 and present in some 2022
| smartphones (Cortex-X2, Cortex-A710, Cortex-A510), which
| implement Armv9.0-A, also support PAC.
| gjsman-1000 wrote:
| Edit: Correction, ARMv8.3, not ARMv8.2.
| flerp wrote:
| Adlink ahoy
| kurupt213 wrote:
| Probably an M2 vulnerability too?
| pizlonator wrote:
| So an attacker who needs to bypass PAC can already sometimes find
| a nonspeculative PAC bypass, though it's hard. Assuming they
| can't, maybe they can use this, if they can find and weaponize an
| appropriate gadget in the kernel. Sounds plausible but hard;
| maybe harder than finding a nonspeculative PAC bypass. Any
| speculative PAC bypass will also suffer from nondeterminism, so
| it's not as practical for an attacker as a nonspeculative bypass.
|
| It's not a given that the speculative PAC gadgets in any kernel
| are exploitable as effectively as the synthetic kext gadget in
| the paper.
|
| Even if you find a weaponizable PAC gadget in the kernel, and it
| actually gives you what you want, it's not clear how reliable
| it'll be in practice.
|
| So, this is kinda scary but it's also a bit of theatre. The tech
| press will have something to write about though.
| ENOTTY wrote:
| As someone with a bit of experience in this area, IMO, the
| Techcrunch article is more confusing than it should be.
|
| Here's a link to the actual abstract. The work will be presented
| at ISCA, which will start on June 18.
| https://dl.acm.org/doi/10.1145/3470496.3527429
|
| Here's a link to MIT's press release.
| https://www.csail.mit.edu/news/researchers-discover-new-hard...
|
| Here's a link to the vulnerability's website, as is tradition
| now. (Plus the paper) https://pacmanattack.com/
| ENOTTY wrote:
| Having grokked the abstract, I feel like can speculate a bit as
| to what is going on. Take this with a grain of salt; I have no
| clue what has actually been discovered.
|
| I believe that the researchers have found a way to remove PAC
| as a barrier to exploitation by disclosing PAC verification
| results via speculative execution. This is only useful to
| attackers going after a target that uses PAC, and those
| attackers will need to have another vulnerability that enables
| them to hijack control-flow through modifying pointers to code
| that are located in memory.
|
| The attackers can use this new Pacman vulnerability as a crash-
| free oracle that says whether their forged pointer worked, and
| once they find a working one, they can use that to hijack
| control flow.
|
| PAC (or Pointer Authentication) is a security feature found in
| recent iPhones, the Apple Silicon Macs, and the Graviton3. It
| is intended as a defense against control-flow hijacks. It works
| by signing pointers found in memory with one of five keys that
| are known only to the processor. Before the pointer is used,
| the processor should be instructed to "authenticate" the
| pointer by checking the pointer's signature using its private
| keys. To prevent simple reuse of one authenticated pointer used
| in one place to a pointer used in another place in the program,
| code can provide a "context" value to be used during the
| authentication.
|
| A great resource for learning about PAC and its usage in the
| Apple platforms is at [1] (it links to other resources) and if
| you want to play with a PAC enabled binary, check out [2]
|
| [1]: https://googleprojectzero.blogspot.com/2019/02/examining-
| poi...
|
| [2]: https://blog.ret2.io/2021/06/16/intro-to-pac-arm64/
|
| EDIT: The attack works by:
|
| 1) Place your guess such that it is used as the pointer input
| to an authentication instruction
|
| 2) Causing a branch misprediction. On the not-taken side of the
| branch, code needs to perform a pointer authentication and
| usage of the pointer. On the taken side of the branch, code
| should not crash.
|
| 3) CPU speculatively executes down the not-taken side of the
| branch (misprediction) and speculatively executes the
| authentication instruction.
|
| 4) If your guess is correct, the authentication instruction
| will return a valid pointer. If your guess is incorrect, the
| authentication instruction returns a pointer that, if
| dereferenced, will cause an exception.
|
| 5) CPU speculatively executes a load (in the case of a data
| pointer) or an instruction fetch (in the case of a code
| pointer) on the pointer value.
|
| 6) If the pointer is valid, the address translation for that
| pointer will appear in the TLB. If the pointer is not valid, it
| will not (because of the exception).
|
| 7) All of the effects from this mispredicted branch get
| squashed when the CPU realizes that the branch is not taken. No
| exception is actually thrown!
|
| 8) Measure the TLB entries to determine whether the speculative
| address translation made it in. If it is present, you know that
| the guess is correct.
|
| 9) Repeat, up to 2^16 times.
| jprx wrote:
| You hit the nail right on the head! That's exactly what we
| did :)
| twoodfin wrote:
| Apparently they haven't fixed it yet, so a hardware
| solution may in fact not be possible, but is there any
| reason to believe it couldn't be patched in "microcode"?
|
| Who can guess at the performance impact, but one could
| imagine a configurable mechanism capable of disabling
| speculation past a PAC authentication.
| sizzle wrote:
| Amazingly articulate writing, I think you have a second
| career as a tech writer if you ever wanted
| Mo3 wrote:
| And this can really not be fixed in any way? Not trolling,
| happy to barely understand this in the first place
| Findecanor wrote:
| Until it has been fixed in hardware I think it could be
| mitigated in software a bit, but at a cost. A PAC signature
| can include also a 64-bit "context" value, which you could
| make unique per pointer (like a nonce).
|
| However, context values are not something that is supported
| by any C ABI: the PAC extension contains also instructions
| that hardcode the context value to zero, and I would guess
| that those are what the kernel is using currently. To make
| use of context values, I suppose you would have to use a
| new ABI that stores effectively 128-bit pointers, and which
| also creates the random nonces/keys/whatyoucallthem to
| store in them.
| ljhsiung wrote:
| Personally, I believe it can be fixed via key rotation
| (e.g. there are 3 inputs to the PAC algorithm. The pointer,
| a "modifier", and a "key" e.g. APIAKey_EL1).
|
| I would have added that as a potential mitigation in the
| mitigations section. I think, say, changing the key every
| so often would be a reasonable task for a kernel to do,
| especially in the timeframe that this was exploited (about
| 3 minutes)
| jprx wrote:
| Hi! This is an interesting idea. However, there is a
| problem that arises- if you rotate the key, then old
| pointers now become invalid. And since the kernel is
| always alive and servicing requests (and contains
| structures with very long lifetimes) we don't believe
| this to be a practical solution.
| frankfrankfrank wrote:
| Considering all we have learned over the years, it is not
| unreasonable to wonder whether this "flaw" isn't there by design
| to meet some secret American government vulnerability
| requirement.
| mike_hock wrote:
| The NSA is holding a portfolio of undiscovered vulnerabilities,
| whether they've been planted by its operatives or discovered by
| its researchers. Old ones get discovered independently and
| patched, new ones get created, all the time.
|
| Sending men in black or a top secret letter to a company and
| demanding a back door has to be the clumsiest possible way to
| go about introducing a vulnerability. It creates way too many
| people in the know, anyone could disclose it to researchers
| like OP who could then claim to have found it independently.
|
| It's way more effective to have moles on your payroll.
| GeekyBear wrote:
| Isn't pointer authentication a feature of the ARM 8.3 instruction
| set and not an Apple specific thing?
| als0 wrote:
| Yes, it's defined by ARM. Though the unsafe implementation of
| speculative execution is obviously by Apple.
| GeekyBear wrote:
| Is Apple's implementation the only vulnerable implementation?
|
| Prior speculative execution issues applied to more than one
| vendor's implementation.
| adrian_b wrote:
| Except for the Apple CPUs, only the ARM cores introduced in
| 2021 implement this.
|
| It remains to be seen whether their implementation is
| better.
|
| Until now only few people had access to such recent CPUs,
| which can be found only in the 2022 models of some
| smartphones and in the new Graviton 3 servers, so they did
| not receive much scrutiny.
| formvoltron wrote:
| ummm. Could this flaw be attacked via the web? And Apple cannot
| fix it?
| pineconewarrior wrote:
| No, not without several other 0-days to exploit. See the other
| comments here.
|
| Essentially, the attacker must have access to another buffer
| overflow of some sort.
|
| This is only a bypass for a specific line of defense, called
| PAC - a security feature introduced recently in ARM 8.3. By
| itself, it is not enough to attack a system at all.
| cosmiccatnap wrote:
| I wonder at what point we will finally give up on trying to make
| a stable implementation of speculative execution.
| homodeus wrote:
| Any reason they aren't using formal verification for this kind
| of thing? It would seem like a very worthy investment.
| xxpor wrote:
| The moment someone wants to take the economic hit of a decade+
| of performance progress.
|
| IOW, not gonna happen.
|
| I could see coprocessors becoming more popular though. We
| already have AES-NI, what if the sensitive keys never ended up
| in CPU cache because the CPU never had to see them? Specialized
| HW could not have speculative execution. Granted, that doesn't
| prevent seeing the plain text of something that's decrypted.
| It's all about the threat model and what tradeoffs you're
| willing to make.
|
| And that's why Intel et al haven't completely abandoned
| speculative execution. For the vast vast vast majority of
| people, the security issues they're much more likely to deal
| with are straight up getting scammed. Not 0 days, and
| especially not insane stuff like this. Unless you can turn it
| into a zero-click iMessage bug (or similar), meh.
| [deleted]
| olliej wrote:
| My reading implies you need actual code execution already? As you
| need to be able lay down the actual auth instruction that you
| want to force? (Eg nothing so horrific as simply running js)
|
| Hahah, ok now I have a much better understanding.
|
| It requires an existing path to arbitrary code execution, and a
| buffer overflow or some such in kernel space.
|
| So yes this does defeat one part of the M1 defensive system,
| which is clearly suboptimal, but the way the article portrays it
| is absurd.
| calo_star wrote:
| I find it so frustrating and disgusting that articles like this
| don't link to the original research paper/publication.
| jprx wrote:
| Hi! Joseph (one of the authors) here. You can read more about our
| attack here: https://pacmanattack.com
| guardiangod wrote:
| (Will read the paper later)
|
| How lawyer-y do you think Bandai Namco will be?
| mnd999 wrote:
| Would have thought Arch Linux would have more of a case for
| their package manager (Pacman) seeing as now it could be
| confused with an exploit.
| wyldfire wrote:
| If they are - Joseph and MIT, please stand up to them. The
| standard for infringement is confusing similarity.
| Researchers aren't marketing goods and there's no risk of
| confusion.
| bogwog wrote:
| They probably won't care about this, although I do find it
| weird when researchers make a whole website with custom
| domain just to publish something like this. Personally, it
| comes off as less trustworthy since it enters the same realm
| of bullshit as those market manipulation attacks on AMD a few
| years back[1]
|
| Not saying that's what this is (I'm sure these are legitimate
| findings), but this tactic raises some red flags for me.
|
| 1: https://www.gamersnexus.net/industry/3260-assassination-
| atte...
| MertsA wrote:
| Yeah I hate this trend of naming vulnerabilities and
| pandering to the tech press. The CTS Labs FUD was just
| beyond the pale. Most tech journalism just ate up those
| claims that were clearly B.S. and not even self consistent.
| They were claiming it was impossible for AMD to patch with
| firmware or microcode but in the same sentence claiming an
| attacker could use it to create a rootkit that couldn't be
| removed. Nobody bothered taking two seconds to think
| critically about what they were publishing to realize they
| were claiming that it was, in essence, somehow possible for
| an attacker to "pull up the ladder behind them" but not for
| AMD.
|
| Maybe this "unpatchable flaw" with the M1 has some more
| legitimacy than the "critical AMD vulnerabilities" back in
| 2018, but please, stop with the stupid trendy names for
| vulnerabilities. Lets discuss this on the technical merits
| and skip the marketing.
| azinman2 wrote:
| Actively marketing yourself and your ideas is one of the
| most important things you can do. Without, most people
| simply won't know about it or will dismiss it. Just
| because you market it, doesn't mean it'll be successful -
| things still have to prove their worth regardless and
| will otherwise fizzle out.
|
| How many important security vulnerabilities have just had
| technical white papers and no marketing have gotten wider
| coverage? Very, very few. It's also very useful for
| humans to talk about something when given a short,
| memorable name.
| virgulino wrote:
| >Yeah I hate this trend of naming vulnerabilities and
| pandering to the tech press.
|
| It is not a trend. It's a tradition:
|
| Back Orifice. Ping of Death. Smurf Attack. Computer
| Viruses. Computer Worms. (Hello Robert Morris!)
| adamsmith143 wrote:
| Hey Joseph,
|
| How does one prove that a hardware exploit is actually
| 'unpatchable'?
|
| Thanks
| jprx wrote:
| This is a great question! What this means is that a software
| patch cannot fix the speculative execution behavior that
| causes the PACMAN issue since it is built directly into how
| the hardware operates.
| adamsmith143 wrote:
| So there is no possible set of instructions that could
| block the particular behavior in the exploit?
| jprx wrote:
| You could maybe do it with lots of fences or just a
| ridiculous chain of NOPs after each branch such that the
| ROB is cleared before you have time to try to load a
| pointer speculatively.
|
| In practice, both of these would probably kill
| performance, so I don't think either of these are great
| solutions. Recall we are targeting the kernel where
| everything needs to be as fast as possible.
| ljhsiung wrote:
| Hi Joseph! Go Illini! I didn't see you my last semester but I'm
| glad to see Chris's members doing well in the world. Also
| always love Mengjia's work.
|
| 2 questions.
|
| 1) it's relatively known that PAC is brute-forcable given its
| relatively small key space (16 bits, sometimes 8 if TBI is
| enabled). How does your attack differ from general brute
| forces? (My impression is just your leveraging of the BTB/iTLB
| is a bit more stealthy.) Similarly, in your opinion, would a
| fix be more ISA-level or you think it's more specific to the M1
| (given brute forcing in general is a PtrAuth problem)?
|
| 2) you mention in section 8 that this took 3 minutes for a 16b
| key and tons of syscalls. Wouldn't another proper mitigation be
| to limit the number of signatures per key? 3 minutes is
| definitely a long time, and some form of temporal separation
| may be quite helpful.
| jprx wrote:
| ILL-INI!!!
|
| 1) Our attack does apply a brute force technique with the
| twist that crashes are suppressed via speculative execution.
| If you tried to brute force a PAC against the kernel, you'd
| instantly panic your device and have to reboot.
|
| 2) Given that we never sign anything (only try to verify a
| signed pointer), and that every authentication attempt
| happens under speculation, I'm not sure how you would rate
| limit this without absolutely destroying performance. Keep in
| mind the kernel is doing a whole lot more with PAC than just
| our attack (for example, every function's return address is
| also signed with PAC) so distinguishing valid uses from a
| PACMAN attack might be challenging.
|
| I suppose you could track how many speculative PAC exceptions
| you got, but it's a little late to add that now isn't it? And
| it could also raise lots of false positives due to type
| confusion style mechanisms on valid mispredicted paths.
| ljhsiung wrote:
| Thanks for the quick answers.
|
| Third Q-- What's your opinion on BTI as a possible
| mitigation? Given it's an v8.5 feature meant for JOPs, and
| this attack is essentially a speculative JOP, maybe we
| could use BTI to mitigate and heavily reduce the number of
| gadgets, speculative or not.
| lamontcg wrote:
| Is PAC something like the old GCC stackguard canary mechanism
| done in hardware?
| jprx wrote:
| You can think of it a lot like that! PAC is more advanced as
| you can describe what a pointer "should" do on access (aka is
| this a data or code pointer?).
| vletal wrote:
| You were in touch with them since 2021. Did they manage to fix
| it for M2? Or is it also valnerable?
| tambre wrote:
| That's too short of a timeframe in the silicon world. If it's
| considered important we'll see something in M3, but more
| likely in M4.
| tikkun wrote:
| Sounds like it requires physical access to a device, is that
| right? At least less of a concern than software only, though
| still not good.
| TazeTSchnitzel wrote:
| As the article puts it, it's a breach in "last line" security
| defences. Specifically, it's a mitigation that applies when you
| _already_ have code execution. It 's nothing for most people to
| worry about. PACs are a new mitigation that Intel Macs didn't
| have, so it's not like it puts the M1 in a worse position than
| what it replaced.
| amelius wrote:
| > it's a mitigation that applies when you already have code
| execution
|
| Sounds like a huge deal if you want to run untrusted code
| inside a sandbox.
| tempay wrote:
| You still need a sandbox escape before this mitigation
| kicks in.
| adrian_b wrote:
| This is a new security feature, which few computers have, so
| the fact that it does not work obviously has little practical
| importance. At worst it makes the new computers with this
| feature only as secure as any old computer.
|
| Nevertheless, the article is very important, because it shows
| that this supposedly security-improving feature has been
| implemented in a way that makes it useless (like it has also
| happened with some Intel security features, e.g. Software
| Guard Extensions).
|
| Everybody must become aware that this "pointer
| authentication" feature is currently unreliable, so it must
| not be used, and the designers of future CPUs must take care
| to not repeat these mistakes.
| Someone wrote:
| What are you basing _"so it must not be used"_ on?
|
| I would think it can't harm, ever.
| adrian_b wrote:
| Like you say, it does not do much harm if used.
|
| Nevertheless, there is some small loss of performance,
| because instructions to compute the Pointer
| Authentication Code (PAC) must be inserted in the
| program, and possibly also instructions to authenticate
| the PAC, though the latter may be omitted if the function
| return instructions and the indirect jumps through
| pointers are replaced with instructions that combine the
| pointer authentication with the jump.
|
| I have no idea whether on the Apple CPUs the
| jumps/returns with authentication have the same speed
| with the simple jumps/returns.
|
| I suppose that the Apple compiler adds automatically the
| PAC computation and authentication instructions, so using
| this option does not increase the complexity of the
| source code.
|
| Nevertheless, even if the performance impact of using PAC
| might not be important, whenever a security feature that
| does not work is used, there is the danger that there
| will be some people who do not know that it does not
| work, so they will believe that exploits are impossible
| and there is no need to be careful to avoid the
| possibility that an adversary might be able to modify a
| pointer, e.g. by crafting a special input to the
| application.
|
| In general all the variants of pointer validation that
| have been recently introduced in all CPU architectures
| are just workarounds against the bugs introduced by
| programmers, because in a well written program there
| should be no way for an adversary to modify an internal
| pointer.
| astrange wrote:
| "All programs must be well written" with nothing in the
| ISA to help you write them properly isn't a good way to
| do software. PAC helps you reduce bugs because it
| checksums your pointers.
| dreamcompiler wrote:
| Security techniques that have known workarounds cause
| harm by engendering a false sense of security.
| [deleted]
| _kbh_ wrote:
| nearly every security feature in existence has known
| (situation dependent) work arounds. That does not mean
| you should turn them off.
| donkarma wrote:
| Skimmed this really fast, but is this just bypassing PAC by
| brute-forcing the code with speculative execution?
| jprx wrote:
| Pretty much!
|
| (There are a few aspects that make this challenging in
| practice, but that's the idea).
| UncleOxidant wrote:
| Since the M1 is not being used in servers, how big of a deal is
| this?
| [deleted]
| BLO716 wrote:
| The growing pains of silicon development date back to the Intel
| line of Pentium FDIV bug issues. Not surprised it occurred, just
| surprised it took so long to come to fruition. I can only think
| its the lack of hardware engineers savvy enough to exploit such
| an issue, since the abstractions from hardware are so far removed
| from us general populous software developers.
|
| Any thoughts on the above?
| stevenjgarner wrote:
| For the uninitiated, are such 'unpatchable' hardware flaws
| prevalent and/or debilitating to a greater or lesser degree in
| other processors (Intel, AMD, Apple AX processors)? Or has
| Apple "dropped the ball" compared with other chip designers?
| depereo wrote:
| You can look up some other major events such as
| spectre/meltdown which also used hardware side channels and
| speculative execution, or rowhammer which affects RAM.
| stevenjgarner wrote:
| Interesting! Were the unit testing procedures used in the
| hardware design and simulation processes themselves flawed?
| Reading up on these I have not yet been able to elucidate
| any forensic insight into the original chip design.
| dang wrote:
| Related:
|
| https://pacmanattack.com/
|
| https://spectrum.ieee.org/pacman-hack-can-break-apple-m1s-la...
|
| (via https://news.ycombinator.com/item?id=31694844 and
| https://news.ycombinator.com/item?id=31694017, but we merged the
| latter hither and the former had no comments)
| schroeding wrote:
| OT, but is anyone here also redirected to "https://guce.advertisi
| ng.com/collectIdentifiers?sessionId=3_...", which gets blocked by
| uBlock Origin? It's a HTTP redirect.
|
| This only happens with my IPv6 landline internet connection
| (german carrier Telekom), via IPv4 mobile internet (T-Mobile) it
| loads fine. Happens with two different devices, so it shouldn't
| be a compromised device, Techcrunch TLS certificate is valid, so
| it also should not be a compromised router or my ISP. Are they
| A/B testing?
| ev1 wrote:
| This is Techcrunch first-party native. If it can't set a third
| party tracking and fingerprint cookie, instead it will
| forcefully HTTP redirect you through that to drop a "first
| party" cookie.
|
| NB: techcrunch is basically advertising.com (via
| aol/yahoo/oath/verizon media/whatever else)
| markovbot wrote:
| Yeah, I'm getting this too. TechCrunch somehow managed to get
| even worse.
|
| edit: https://spectrum.ieee.org/pacman-hack-can-break-
| apple-m1s-la... seems to cover the same thing with less spyware
| jeroenhd wrote:
| Not on my side, but it wouldn't be the first time some third
| party advertising server would be serving malware. Malvertising
| will restrict itself to only some visitors to make sure it's
| not detected and blocked too quickly.
|
| The massive cookie wall I'm met with when opening this site
| makes it clear that it's probably impossible to determine which
| third party is responsible this time.
|
| You can read the article safely here:
| https://12ft.io/proxy?q=https%3A%2F%2Fweb.archive.org%2Fweb%...
|
| The web archive also seems to be redirected for some reason,
| though that might as well be intentional.
|
| Edit: thinking about it, this might also be an attempt to use
| first party tracking to bypass third party cookie restrictions.
| Maybe they're A/B testing a new advertising tool?
| [deleted]
| Nextgrid wrote:
| A domain "advertising.com" is basically the definition of
| malware.
|
| It's Yahoo/Oauth's spyware domain and as the URL suggests it
| "collects identifiers" presumably takes a browser fingerprint
| and sets tracking cookies.
| Rexxar wrote:
| I have this errors on techcrunch for years. I don't remember
| the last time I read something on this site.
| [deleted]
| 0daystock wrote:
| Your browser shouldn't even be capable of resolving
| advertising.com
|
| You can use https://github.com/StevenBlack/hosts as your hosts
| file, but even better is TLD and wildcard domain blocking with
| dnsmasq or dnscrypt-proxy.
| serf wrote:
| >https://pacmanattack.com
|
| >does PACMAN have a logo? >Yes!
|
| great, answering the hard questions.
|
| the trend of creating a marketing website for every horrible
| exploit is so strange. Who are these people selling to, and what?
|
| Fear to media outlets is my only guess.
| josh2600 wrote:
| The answer, as always, is that speculative execution is the
| devil.
|
| I'm not convinced you can write a "for" loop safely on a modern
| processor.
| api wrote:
| Seems like if this were successful it would weaken the _extra_
| security provided by pointer authentication, at worse weakening
| it to the level of a CPU without pointer authentication like the
| x86_64 chips they used to use. So not great but not catastrophic.
| Or am I missing something?
| rs_rs_rs_rs_rs wrote:
| You're right, that's exactly what this is. Just a way to defeat
| a defense in depth measure.
|
| This vulnerability it's useless by itself.
| yosito wrote:
| So not the "last line of defense"?
| Filligree wrote:
| It can reasonably be described as such. The headline
| implies that previous lines of defense have also been
| broken, which isn't the case.
| gruturo wrote:
| It is. It's just that compromising the last line of
| defense, without compromising the ones which come before
| it, is not the end of the world.
|
| It's like if I could wave a magnet over your encrypted
| backup tapes, ruining your restore capability, but without
| having any ability to affect your production and DR sites.
| You'd rather it didn't happen, but you are still up and
| even have redundancy.
| tester756 wrote:
| >is not the end of the world.
|
| today, how many years it took the theory to be applied in
| "real world" with other cpu vulns
| rs_rs_rs_rs_rs wrote:
| I don't think you understand this vulnerability.
|
| This will not become Spectre-like in 10 years from now.
|
| The impact will be the same as it is today.
| tester756 wrote:
| Sorry, I meant chaining vulns, once they do appear
| rc_mob wrote:
| lol. apparently the article title is "technically the
| truth"
| nimbius wrote:
| This is a dangerous position to hold. this vulnerability aids
| in reducing the overall security posture of the OS so its
| quite valuable. it improves an adversaries opportunities and
| however limited, still advances the potential for system
| compromise.
|
| Infosec isnt just home runs, it is iterative, cumulative
| progress toward a shared goal. things like this are what
| ultimately led to XBox and Playstation jailbreaks.
| api wrote:
| This is correct, but at the same time it's important to not
| overhype every single vulnerability as the end of the
| world. Unfortunately some security people seem incentivized
| to do that, and it causes a "crying wolf" problem. Serious
| end of the world announcements should be reserved for
| serious end of the world vulnerabilities.
|
| This is a vulnerability that reduces the security of the
| Apple Silicon platform to being closer to on par with the
| immediate prior platform that Apple is actually still
| selling.
| danaris wrote:
| ...in certain, very restricted circumstances.
| azakai wrote:
| Correct. And, in general, I don't think this worsens it to the
| level of a CPU without PAC. It still takes effort to do this,
| since like SPECTRE, you need the ability to measure time, and
| you need to spend a significant amount of CPU power to get a
| useful signal.
|
| Definitely an impressive result, and it certainly reduces the
| usefulness of PAC, but I'd guess PAC is still going to prevent
| a significant number of attacks.
___________________________________________________________________
(page generated 2022-06-10 23:00 UTC)