9 ms·
New vuln in Apple M-series allowing secret keys extraction can't be patched
- VeejayRampay 3y agoif 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 3y agoIt definitely supports my belief that centralizing identity, payment, and apps into a single device is a fundamentally flawed security model.
- aargh_aargh 3y agoCan 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 3y agoSingle point of failure? If a single code gives access to everything, loosing that code to a malicious actors is really bad.
- AnthonyMouse 3y agoThe 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 3y agoWhat 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 3y agoAs opposed to what else? Please elaborate.
- madsbuch 3y agoUsing 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 3y agoI 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 3y agothat 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 3y agoWhat 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.
- madsbuch 3y agoHey, this is completely up to you. nobody is trying to steal your apple pay. this is merely the parent commenter's belief that they would should use different apps to reduce the risk vector when secrets are stolen. no reason to completely ballistic.
- Kluggy 3y agoIt’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 3y 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 3y agoIsn'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 3y ago[deleted]
- threeseed 3y agoI 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 3y agoThe 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.
- 3y ago
- Angostura 3y agoI imagine something like a software framework that can be called if properly secure crypto is needed at the expense of performance
- junon 3y agoLike a TPM?
- tombot 3y agoActual 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 3y agoactual source of the article: https://gofetch.fail/ https://gofetch.fail/
- shp0ngle 3y agoThe Ars article is arguably more useful than the vuln website, with more added context; it's not just blogspam.
- bluetomcat 3y agoNow looking for an affordable M3 Max MBP that should cost less than my car :-)
- eru 3y agoHere in Singapore, everything that Apple does costs less than any car you could buy.
- sofixa 3y agoI 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 3y agoIf 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 3y 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 3y agoYou 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 3y agosome 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 3y ago[deleted]
- nijaru 3y agoDiscussed here: https://news.ycombinator.com/item?id=39779195 https://news.ycombinator.com/item?id=39779195
- midtake 3y 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?
- SV_BubbleTime 3y agoIsn’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 3y agonope. the side effects (which can be access times in case of non-failure, or voltage changes, or or or...) would still happen
- pjc50 3y agoAbsolutely critical for performance, though. If there's a way out of this it might have to be better virtualization.
- bhawks 3y agoFor 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.
- 3y ago
- switch007 3y agoGoogle, 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 3y agoSome 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 3y agoThe 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 3y agoCorrect. It's still very bad, but does not affect the secure enclave.
- okokwhatever 3y agoAs 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 3y agoThe 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 3y agoI'm sure Apple will provide a patch in the next few days. Mr Tim Cook will take care of the share price.
- boesboes 3y agoAnother 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 3y agoIt's security vs. speed. Can't have both. It's a bit like security vs. convenience.
- TeMPOraL 3y agoOr security vs. usefulness.
- boesboes 3y agoyeah, 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 3y agoSpeculation 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 3y agoSecurity 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 3y agoThis 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 3y agoMy 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 3y 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 3y agoWhat does this have to do with security through obscurity? This is an issue with cache prefetching.
- xpuente 3y agoIt has to with the secure processor. Although you seems to ignore what is the TCB.
- resource_waste 3y agoWow, 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 3y agoMacs 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.
- deleted 3y ago[deleted]
- planb 3y agoUnfortunately, 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 3y agoKim 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 3y agoSuppose 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 3y ago[flagged]
- cyberpunk 3y agoDid 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 3y agoYes. 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 3y agoClickbait. 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 3y agoThe 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 3y 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 3y ago[dupe] Discussion on the actual vulnerability post: https://news.ycombinator.com/item?id=39779195 https://news.ycombinator.com/item?id=39779195
- ryandvm 3y agoSweet. Wonder if this opens the door a DeCSS-style hack for open source iMessage clients?
- 1vuio0pswjnm7 3y agoActual paper: https://gofetch.fail/files/gofetch.pdf https://gofetch.fail/files/gofetch.pdf