7 ms·

New vuln in Apple M-series allowing secret keys extraction can't be patched

• resource_waste 2y ago
  Wow, didn't this happen with Intel? I think that was a noticeable drop in performance. This is probably worse given people were trying to experiment with local LLMs on CPU. Its not like they even offer Nvidia.
  • breckenedge 2y ago
    Macs have GPUs and their architecture means that GPU has access to the full system RAM. Cuda isn’t a requirement for running ML workloads on a GPU.
• VeejayRampay 2y ago
  if this is confirmed I'm really interested into how exactly Apple will somehow deflect this and make it vanish like they somehow always manage to do with the myriad of issues they're facing over and over
  • dalke 2y ago
    It definitely supports my belief that centralizing identity, payment, and apps into a single device is a fundamentally flawed security model.
    • aargh_aargh 2y ago
      Can you elaborate what you mean? I may be misunderstanding what you intended but how do you use traditional means of payment (credit card) without an identity? How do you check your email without identity?
      • madsbuch 2y ago
        Single point of failure? If a single code gives access to everything, loosing that code to a malicious actors is really bad.
      • AnthonyMouse 2y ago
        The premise is that you keep a separate device with the sensitive stuff on it (e.g. the chip in your physical credit card, a physical ID badge), and then you can't click on a link in your email or go to the wrong web page and compromise that data because the device you use for email or browsing never has it to begin with.
      • dalke 2y ago
        What I said was that centralization is the problem. Different tasks require different levels of identification. Cash (a traditional means of payment) requires no identification. I only carry up to about $200 in cash on me, which an amount I'm willing to bear if my wallet is stolen. When I use chip&pin ("what you have and what you know") for small payments, I rarely need any authentication, and when I do it's the PIN. My wife can and has used my card, with my permission. I have my email password written down for her so she can access it, eg, if I die and my computer dies. The banking system probably factors in my usual payment locations to make the choice of when to ask for a PIN, combined with the trust experience with the vendor. My card, even with a PIN, has a spending limit. Years ago I had to authorize raising the limit because my client was willing to reimburse me for a business class flight across the Atlantic. Of COURSE I want more friction in the system when doing something riskier. If the way to authorize a $60 dinner and a $60,000 car are too similar, then it's easier to fool you. For a higher amount, I can go to the bank and carry out a transaction in person, or I can authorize it through their online banking system. "But wait, how?" you might ask. The bank figured this out years ago, when people started going online, using unpatched Windows PCs without virus scanners. The system - whose security I trust much more than a phone's - uses a small device with a camera. The login screen shows me a pattern with colored dots. The camera reads those dots, decodes the message (and probably also validates it cryptographically) and displays a message asking me to verify I want to log in. I enter the PIN, and it generates a response code, which I enter. If I make a payment, or add a new recipient, or a few other things, I am required to use the device again. This device stays at home, because I don't expect to make $10,000 payments while out. I can use it on any web-enabled device, because the security is in "what I have" and "what I know", in a device which cannot be hacked, does not require any physical connection, and does not require network accessed. I like this system more than a Yubikey because it does not require a hardware attachment, which isn't always possible. Yes, Yubikeys feel like a step backwards compare to my bank's security practice. I don't understand why there is no provision for cable-free/wifi-free/mobile-system-free validation in this supposed privacy-oriented switch to passkeys, when I know such a system exists. Furthermore, the bank has the legal obligation to ensure the system works. If the encryption system is somehow broken, they are required to update the hardware. Apple is not. Yubi is not. The cost is all on you. My bank has even shut down mobile phone banking for older hardware/OSes, claiming the security isn't high enough. But they have not needed to update my security device. If you expect your phone to be able to do anything, and authorize anything, then I see it as a giant risk. You can be at the bar, drank to much, and be convinced to make a payment or authorization that you shouldn't of. There's no real, physical way to change your risk level depending on the circumstances if you always have your phone with you. Centralization of identify, payment, and apps is fundamentally flawed.
    • EtienneK 2y ago
      As opposed to what else? Please elaborate.
      • madsbuch 2y ago
        Using multiple devices: Credit cards for payment, instead og apple pay. A camera for taking pictures, instead of a camera app, a notebook to write notes, instead of an app. From my perspective the original comment is not rocket science?
        • electric_mayhem 2y ago
          I learned from another commenter on HN when a post asks low-effort questions where the answer is common sense or implicitly understood, it’s most likely a bot or troll or shill. Best not to engage with them.
          • madsbuch 2y ago
            that makes sense. within the past couple of months the value of comments, especially before community cueation, has gone very much down. Maybe hackernews is mostly LLMs speaking at this point. what a shame.
        • threeseed 2y ago
          What an awful and counterproductive experience. If you require someone to enter their credit card number every time they make a purchase they end up doing dumb, insecure things like storing it as a text file on their desktop. And having external hardware just means more cables, batteries, updates to keep it secure etc. Initiatives like PassKey, ApplePay, TouchID etc. have been a huge win for security and privacy.
          • dalke 2y ago
            I don't want to require everyone to do that. I'm fine if others are willing to accept the risks of centralization of identify, payment, and apps into a single device. I understand the benefits you say are true for many people. I don't want to be forced into that model because I think it's too risky. I think YubiKeys and other devices which require physical device attachment to use to be too risky when I know other solutions exist (see a parallel comment, or below). I want to teach my kids that if a phone is asking for permission, asking to verify id, asking to read complex terms of services, then you must be careful, and preferably not trust them. The current model is "identify yourself whenever the computer asks" and "click I Agree", which seems open to all sorts of abuse of power and trust. How many people know they are giving up their rights to a trial in favor of forced arbitration? How many read the license which says to email 'law@example.com' to not waive that right? How many are able to understand the relevant issue? Effectively zero. Are high schools going to start teaching contract law so students are able to understand what they are expected to sign? No. I also think switching to 2FA and passkeys empowers the Google and Apple duopoly. What happens if you lose your phone? How do you reestablish your passkeys? "Simple. In your new phone, log back in to your Google or Apple account", right? And if Google or Apple shuts down your account for some reason? "Umm, make backups? Also have a YubiKey?" That's a huge lock-in for the sort of people who would otherwise store their passwords in a cleartext file. At the very least everyone should be able to let their bank or other trust third-party store a copy of the end-to-end encrypted database, and that bank or third-party should have an enforceable legal obligation to store, maintain, and provide that encrypted database, and that new phones can restore from this database without needing Apple or Google authorization, after the person has physically visited the bank or police station and identified themselves sufficiently. And if I say I want something more secure and more portable than a YubiKey to log in? My bank login device has had one change of AAA batteries in about 7 years. It has had zero updates, because it is not programmable. It uses a camera to read something like a QR code, a screen to read the requested task, a number pad to enter a PIN, and I can read the response code on the screen, to enter into the computer. It can work with any device, even ones without available plugs. (And my bank is legally responsible for ensuring the security level is enough, and updating if it is not. Apple is not. Google is not.) While I love it for bank login (it's the orange one at https://www.sparbankenskane.se/privat/digitala-tjanster/sakerhetsdosor.html https://www.sparbankenskane.se/privat/digitala-tjanster/sake... ) I also don't want that for all my services! If I need to pull it out, I know that I'm doing something that requires extra attention and care. The rituals needed for different levels of authorization should be very different, to make it hard to get confused about what you are doing. I also have the ability to physically leave my higher authentication devices at home while I'm out for the day. (UPDATE: acdha correctly pointed out the phishing attack possible in this approach. I do not know what the bank does to protect against phishing. But since this is a low-use service, which is unlikely to be targeted, and I am fastidious about double-checking, it seems like a low risk issue. Security through diversity.) Why should I trust ApplePay's privacy more than I do my bank's? Is ApplePay required to follow the same Swedish privacy restrictions that my bank does? Is ApplyPay equally liable in case of errors? Can the Swedish government audit how ApplePay works and confirm it complies to the same level of privacy as my bank? Every time I look into it, it seems the answers are always "no." Maybe it's changed? Basically, I trust international companies who have abused their monopoly position with my security and privacy far less than I trust the Swedish government.
  • Kluggy 2y ago
    It’s a total non issue for the majority of folks. It requires local access and takes hours under very specific conditions that don’t apply to most people. How often do you run a server that will run arbitrary crypto operations on attacker controlled inputs? Plus all the secrets in the Secure Enclave are immune to this attack, so your FileVault keys and your Apple Pay cards and all that jazz are completely safe. It sucks that it exists, and crypto libraries that run on the platform outside of the Secure Enclave will get slightly slower, but no one will notice.
    • switch007 2y ago
      > It’s a total non issue for the majority of folks People said the _exact_ same thing about Spectre/Meltdown. Then the JS PoCs came out
      • Aaargh20318 2y ago
        Isn't the lesson here that scripting in the browser needs to die. Letting untrusted code run on your computer is always a bad idea, no matter how much you try to sandbox it.
        • deleted 2y ago
          [deleted]
        • threeseed 2y ago
          I would also love to see the API surface of the browser come way down. If people knew just how widespread and effective browser fingerprinting is they would be shocked. It's Cambridge Analytica on steroids.
      • Dalewyn 2y ago
        The SpectreMeltdown mitigations have caused me more grief than the problem themselves to this day. These vulnerabilities definitely exist, that much is a matter of fact. But whether it's something someone should consider in their threat model is a different matter.
      • 2y ago
  • Angostura 2y ago
    I imagine something like a software framework that can be called if properly secure crypto is needed at the expense of performance
    • junon 2y ago
      Like a TPM?
• tombot 2y ago
  Actual article https://arstechnica.com/security/2024/03/hackers-can-extract-secret-encryption-keys-from-apples-mac-chips/ https://arstechnica.com/security/2024/03/hackers-can-extract...
  • SuchAnonMuchWow 2y ago
    actual source of the article: https://gofetch.fail/ https://gofetch.fail/
    • shp0ngle 2y ago
      The Ars article is arguably more useful than the vuln website, with more added context; it's not just blogspam.
• bluetomcat 2y ago
  Now looking for an affordable M3 Max MBP that should cost less than my car :-)
  • eru 2y ago
    Here in Singapore, everything that Apple does costs less than any car you could buy.
    • sofixa 2y ago
      I know you're exaggerating because car prices in Singapore are very high (with good reason and kudos to the Singapore government for handling this well), but it's not true: There are a bunch of second hand cars below 6000 Singapore Dollars on this website[1], which is the price of the 64GB/1TB Mac Studio[2]. 1 - https://www.sgcarmart.com/used_cars/listing.php?MOD=&PRC=18&DEP=0&RGD=0&VEH=0&AVL=2 https://www.sgcarmart.com/used_cars/listing.php?MOD=&PRC=18&... 2 - https://www.apple.com/sg/shop/buy-mac/mac-studio https://www.apple.com/sg/shop/buy-mac/mac-studio
      • dagmx 2y ago
        If you’re looking at second hand cars to make your point, shouldn’t you also look at second hand computers too? Also why look at a mid tier upgrade spec when you’re looking at a bottom tier car?
        • eru 2y ago
          > If you’re looking at second hand cars to make your point, shouldn’t you also look at second hand computers too? Nah, my cheeky statement didn't talk specifically about new cars only. So it's only fair to look at second hand cars. I was specifically talking about the most expensive Apple products vs the least expensive cars.
      • coolspot 2y ago
        You forgot one little thing that you need to buy a car, which is the Certificate of Entitlement that you need to own a car in Singapore. So it is $6,000 (car) + $100,000 (CoE)
• Mortiffer 2y ago
  some people's real world take https://www.reddit.com/r/MacOS/comments/1bkd3m4/unpatchable_vulnerability_in_apple_chip_leaks/ https://www.reddit.com/r/MacOS/comments/1bkd3m4/unpatchable_...
• deleted 2y ago
  [deleted]
• nijaru 2y ago
  Discussed here: https://news.ycombinator.com/item?id=39779195 https://news.ycombinator.com/item?id=39779195
• midtake 2y ago
  > The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. Are we nearing any sort of consensus that any form of speculation is bad? Is there a fundamentally secure way to do it?
  • datadeft 2y ago
    It is bad, it is required for performance reasons. The questions is what could be the solution going forward, which is going to be a huge change anyway. I do not see a way out of this with our current architectures.
    • crest 2y ago
      Neither block ciphers, nor stream ciphers, nor common public key algorithms (RSA, Ed25519) need or even profit from this. They just need fast access to the register-register math, maybe loop sequentially through all members of a fixed sized array a fixed number of times. The only thing those implementing such algorithms would probably like having is a few kiB of safe to access scratchpad memory for code and data. On entry to the crypto code copy the code and data there, enable a constant time mode for compute instructions and run the algorithm at full speed without worrying.
  • SV_BubbleTime 2y ago
    Isn’t the issue more akin to use after free? If the instructions and memory were wiped on prediction path failure wouldn’t that help?
    • black_puppydog 2y ago
      nope. the side effects (which can be access times in case of non-failure, or voltage changes, or or or...) would still happen
  • bhawks 2y ago
    For cryptographic applications yes. That is why people have spent significant effort to implement constant time algorithms to replace standard math and bitwise operations. At the hardware level any optimizations that change performance characteristics locally (how long the crypto operation directly takes) or non locally (in this case the secrets leak via observation of cache timings in the attacker's untrusted code) are unsafe. Intel DMPs already have a flag to turn off the same behavior that was exploited on the M1/M2. Which may suggest that the risk of this type of optimization was understood previously. Mixing crypto operations with general purpose computation and memory accesses is a fragile balance. Where possible try utilizing HSMs, yubikeys, secure enclaves - any specialized hardware that has been hardened to protect key material.
• switch007 2y ago
  Google, in 2021 [0]: > While the PoC demonstrates the JavaScript Spectre attack against Chrome 88's V8 JavaScript engine on an Intel Core i7-6500U 'Skylake' CPU on Linux, Google notes it can easily be tweaked for other CPUs... It was even successful on Apple's M1 Arm CPU... And Augury [1] in 2022 also affected Apple's A14 and M1 chips. So have Apple been attempting to mitigate and failing, or ignoring the issue? Surely chip manufactures can't keep ignoring these fundamental flaws [0] https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html https://security.googleblog.com/2021/03/a-spectre-proof-of-c... [1] https://www.prefetchers.info/ https://www.prefetchers.info/
  • acdha 2y ago
    Some of the authors of this paper worked on Augury, too, but note that this is a different angle than Spectre: that was speculative execution (running instructions before knowing which way a branch would evaluate) and this is data prefetching. The reason this keeps coming up is that it isn’t a single issue but a class of attacks exploiting performance features, and attackers are getting more sophisticated as smart people figure out new techniques. Chip designers have been adjusting but are trying not to throw out the last couple decades of performance improvements, too.
• camkego 2y ago
  The title to article ..."secret keys"... had me thinking that this vuln might be a path to extracting the private keys from the secure enclave. I'm not sure, but after a bit more reading, it sounds like private-keys or symmetric-keys can be extracted from other user-space or possibly kernel-space code execution. And NOT from the secure enclave. Just for what it's worth.
  • StewardMcOy 2y ago
    Correct. It's still very bad, but does not affect the secure enclave.
• okokwhatever 2y ago
  As usual nobody cares about the "Average users". This is a flaw, this is a very high risk issue for everyone and should be threaded as a big problem by Apple but as the "average user" is not important anymore...
  • acdha 2y ago
    The average user is compromised by social engineering, password reuse, or not installing updates. If you’re trying to improve matters for them, put your energy into getting them to adopt passkeys and patching promptly, and asking regulators for stricter penalties for phone number spoofing and delivering spam calls. I would wager that there are more people compromised every minute that way than will ever be compromised by this bug.
• igtztorrero 2y ago
  I'm sure Apple will provide a patch in the next few days. Mr Tim Cook will take care of the share price.
• boesboes 2y ago
  Another day, another speculative execution vuln.. IMHO: all this speculation is a local maximum and it show we have fundamental issue with how we design 'computers'
  • layer8 2y ago
    It's security vs. speed. Can't have both. It's a bit like security vs. convenience.
    • TeMPOraL 2y ago
      Or security vs. usefulness.
    • boesboes 2y ago
      yeah, my thinking is we are to focussed on the current state-of-the-art approaches (i.e ooo superscalar, ht, memory architecture etc) where we can eek out the last few % of performance. I wonder if doing something radically different, would have a different tradeoff for performance vs security/trust.
    • yencabulator 2y ago
      Speculation is just a kludge trying to speed up a legacy architecture. It is possible to obtain speed even without speculation, just not without some other fresh ideas. For example the vaporware Mill architecture is in-order on the CPU level but compilers can optimize to run code very concurrently.
• xpuente 2y ago
  Security through obscurity is really a bad idea, and Apple is no exception. In the long run, this will likely drive the adoption of RiscV as a better alternative.
  • colejohnson66 2y ago
    This RISC-V evangelism is worrying. Using RISC-V doesn't make your system secure; Good ISA implementations do. The ISA has no bearing on security vulnerabilities. Perhaps a faulty decoder could be a vulnerability vector, but a faulty RISC-V decoder wouldn't be compliant, and neither would a faulty ARM decoder. If I add a custom crypto extension to a RISC-V core and implement it badly, is that the fault of RISC-V? No! It's my own. And RISC-V doesn't help anyone here because their license allows me to keep my extension completely closed source - no different than Apple is today with ARM.
    • xpuente 2y ago
      My comment was not about the ISA implementation or specification, It's about the TCB (trusted compute base), which in Apple (like intel and AMD) is closed. In RiscV is open. I would recommend you to educate yourself on any topic before lecture others.
    • snvzz 2y ago
      >The ISA has no bearing on security vulnerabilities. Complexity leads to bugs, some of which are going to be security bugs. ISAs impose complexity upon implementations. To claim they do not matter would be disingenuous.
  • tzs 2y ago
    What does this have to do with security through obscurity? This is an issue with cache prefetching.
    • xpuente 2y ago
      It has to with the secure processor. Although you seems to ignore what is the TCB.
• deleted 2y ago
  [deleted]
• planb 2y ago
  Unfortunately, I don't think the real world applications of this exploit are explained anywhere. From skimming the paper , it looks like the attacker needs to be able to a) run code on the victim's machine and b) trigger the encryption process ("For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform private key operations.") So for a) it might be sufficient to run javascript and for b) of course there are ways to inject data into server processes, processing data submitted by clients is what servers are for. But a happens on clients (web browsers) and b would be a way to extract encryption keys from servers. But in what case can an attacker run code on a machine where they can also trigger the encryption (constantly for an hour like in the demonstration)? The only thing that comes to my mind would be a server side code-execution-sandbox that runs SSL termination on the same machine. edit: Maybe stealing client certificate keys?
  • amckenna 2y ago
    Kim Zetter has a great post walking through some details and commentary across a few sources, related to the vulnerability - https://www.zetter-zeroday.com/apple-chips/ https://www.zetter-zeroday.com/apple-chips/ > The cryptographic key itself isn’t placed in cache. But bits of material derived from the key gets placed in the cache, and an attacker can piece these bits together in a way that allows them to reconstruct the key, after causing the processor to do this multiple times. The researchers were able to derive the key for four different cryptographic algorithms: Go, OpenSSL, CRYSTALS-Kyber and CRYSTALS-Dilithium. > [Green] notes that in theory this attack might be used to break the TLS cryptography that a computer’s browser uses to encrypt communication between their computer and web sites, which could allow attackers to decrypt that communication to extract a user’s session cookie for their Gmail or other web-based email account and use it to log into the account as them.
  • AnthonyMouse 2y ago
    Suppose you have a MITM attacker, e.g. hotel WiFi. You have any page not using TLS open in a background tab, which the attacker uses to inject javascript. Meanwhile there is a different page open via TLS which you're actively using, so your browser is constantly using the session key to encrypt the traffic. The attacker is now recording the encrypted session and after an hour they crack the session key and can use it to go back and decrypt the traffic.
• weird_fox 2y ago
  [flagged]
  • cyberpunk 2y ago
    Did you actually look at the paper? It’s extremely technical. I can’t imagine the logo took even 1% of the time they spent on this.
    • weird_fox 2y ago
      Yes. I merely meant that I believe blowing those things out of proportion on purpose isn't helping anybody. The reality of vulns like this is that they don't affect the majority of normal people. Everybody wants to be the next cloudbleed.
• dmitrygr 2y ago
  Clickbait. How can someone lacking the real docs for the CPU claim that this “can’t be patched”? How could they possibly know what chicken bits exist to disable what features?
  • Glant 2y ago
    The page for the vuln states there is a bit you can flip to disable the entire feature on the M3, but states no such feature exists on the M1 and 2. If Apple hasn't told them about a similar bit on M1 and 2 in the 100 days since it was reported, there's a pretty good chance it doesn't exist.
  • amckenna 2y ago
    > "After this story published, Apple told [Kim Zetter] they just posted the instruction about the DIT to their web site yesterday [MAR 21], timed to the public release of the researchers' findings, which means that developers were not told to do this fix prior to yesterday's release" [1] The mitigation for the issue was posted in coordination with the publishing of the vulnerability. Given that the mitigation only applies to the M3 processor, it's reasonable to assume that there is no currently known mitigation for the M1 and M2 processors. [1] https://www.zetter-zeroday.com/apple-chips/ https://www.zetter-zeroday.com/apple-chips/
• ChrisArchitect 2y ago
  [dupe] Discussion on the actual vulnerability post: https://news.ycombinator.com/item?id=39779195 https://news.ycombinator.com/item?id=39779195
• ryandvm 2y ago
  Sweet. Wonder if this opens the door a DeCSS-style hack for open source iMessage clients?
• 1vuio0pswjnm7 2y ago
  Actual paper: https://gofetch.fail/files/gofetch.pdf https://gofetch.fail/files/gofetch.pdf