Live data from Hacker News

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

twitter.com

81–90 of 145 posts

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

#81
post #14

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

My personal opinion is that we should solve it the opposite way - don't run untrusted code in the first place (with rare exceptions like dedicating an entire cpu core and a region of memory to a virtual machine, etc). Speculation is one of many side channel attacks, who knows what kind of crazy RF-based exploits are out there. AFAIK we still haven't fully solved rowhammer. I think for "normal" users the main risk is…

the author(s) of the article, completely ignore the cpu itself can be patched. there is microcode underneath the ARM instructions for such scenarios. Look at intel, there has been undocumented microcode for decades I beleive these articles are just hype for street cred.

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

#82
post #76

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.

What does this have to do with security through obscurity? This is an issue with cache prefetching.

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

#83
post #65
post #28

Earlier quoted context omitted.

So you browse the Internet with JavaScript turned off? You're a bigger person than I am ;). The risk here is that there are more individuals with the skills to take this type of attack and bring it to a browser near you. One apps data is another apps code.

I use uMatrix and allow first party JS. When some sites break I open the matrix look at what they would like to load and allow one more origin and reload. An example: chatgpt works by allowing JS from the first party domain, *azure.com and oaistatic.com, which looks like something from OpenAI. It would like to load JS from three other domains but it works even if I don't allow them, so there is no need to let that co…

This is the way.

Unfortunately, I've had no luck getting others to buy into the idea that they should understand this level of detail so they can make these calls. Quite frustrating and depressing, since companies will relentlessly exploit their indifference.

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

#84
post #81

Earlier quoted context omitted.

My personal opinion is that we should solve it the opposite way - don't run untrusted code in the first place (with rare exceptions like dedicating an entire cpu core and a region of memory to a virtual machine, etc). Speculation is one of many side channel attacks, who knows what kind of crazy RF-based exploits are out there. AFAIK we still haven't fully solved rowhammer. I think for "normal" users the main risk is…

the author(s) of the article, completely ignore the cpu itself can be patched. there is microcode underneath the ARM instructions for such scenarios. Look at intel, there has been undocumented microcode for decades I beleive these articles are just hype for street cred.

From what I have read, the microcode on M-series chips is NOT updatable. If this is the case, tsk tsk Apple.

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

#85
post #31

Earlier quoted context omitted.

> For cryptographic applications yes. Why only cryptographic applications? What if I'm writing a very sensitive e-mail, for instance?

For this type of attack to work, the algorithm being run needs to be very well understood, and the runtime of the algorithm needs to depend almost entirely on the secret key. In contrast, the timing of virtually any email operation is not dependent on the contents of the email, other than the size. That is, whether you wrote "my password is hunter2" or "my password is passwor", the timing of any operation running on…

I'm imagining the email program using a formatting and rendering engine, both predictable.

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

#86
post #65

Earlier quoted context omitted.

I use uMatrix and allow first party JS. When some sites break I open the matrix look at what they would like to load and allow one more origin and reload. An example: chatgpt works by allowing JS from the first party domain, *azure.com and oaistatic.com, which looks like something from OpenAI. It would like to load JS from three other domains but it works even if I don't allow them, so there is no need to let that co…

This is the way. Unfortunately, I've had no luck getting others to buy into the idea that they should understand this level of detail so they can make these calls. Quite frustrating and depressing, since companies will relentlessly exploit their indifference.

If other people buy into this idea, then every site will begin proxying third-party javascript.

If the only way to get trackers on the average person is to serve it from the same first-party domain, or to bundle it in with the giant 'app.js', you better believe they'll do that.

Right now, the fact that only a small fraction of people run adblockers, and an even smaller fraction block javascript, is what allows it to work.

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

#87
post #4

Earlier quoted context omitted.

It definitely supports my belief that centralizing identity, payment, and apps into a single device is a fundamentally flawed security model.

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?

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.

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

#88
post #64
post #59

Earlier quoted context omitted.

So, CPUs or cores (and maybe RAM) dedicated to run only trusted and only untrusted code? Examples (I'm running Debian) The kernel, the X11 server, terminal, ssh, bash, anything coming from the official Debian repos including the password manager: in the trusted environment. browsers, electron apps, anything installed from unofficial repos or language and package managers (npm, rvm, asdf, etc): in the untrusted enviro…

> terminal, ssh, bash > X11 server Those can very easily execute untrusted code.

Well it makes no sense to worry about side channel attacks if you don't have isolation in the first place, so there is an implicit assumption that you have a sandboxing layer like VM/container/browser (or the built in unix user separation) which don't care about terminals or X11 (usually a separate X server is used which is running inside the sandbox context).

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

#89
post #72
post #47

Earlier quoted context omitted.

From what I understand, the problem is that algorithms which should be constant time are actually taking a variable amount of time depending on the data. If I have some server software whose security depends on those constant-time algorithms actually being constant time, why shouldn't this be exploitable over the network?

The mechanism is described in the FAQ here: https://gofetch.fail > The GoFetch attack is based on a CPU feature called data memory-dependent prefetcher (DMP), which is present in the latest Apple processors. We reverse-engineered DMPs on Apple m-series CPUs and found that the DMP activates (and attempts to dereference) data loaded from memory that "looks like" a pointer. This explicitly violates a requirement of the…

Thanks for the details, I concluded more or less the same: https://news.ycombinator.com/item?id=39789307
Post reply on HN