Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

61–70 of 145 posts

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

#61

Post by bawolff »

actualwitch wrote: post #25
midtake wrote: 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?

Should we make a petition for apple to make lockdown-like mode that disables speculative execution? I'll sign up for that.

From the gofetch website, apple has already done this for m3 chips.

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

#62

Post by bawolff »

legutierr wrote: post #45
bhawks wrote: post #21

Earlier quoted context omitted.

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)…

> Where possible try utilizing HSMs, yubikeys, secure enclaves - any specialized hardware that has been hardened to protect key material. Are there any circumstances where this hardware is accessible in the browser? As I understand, it is not generally available (if at all) for any cryptography you might want to do in the browser.

In the browser is the primary use case for fido keys.

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

#63

Post by layer8 »

boesboes wrote: post #57

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'

It's security vs. speed. Can't have both. It's a bit like security vs. convenience.

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

#64

Post by sofixa »

pmontra wrote: post #59
PhilipRoman wrote: post #24

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…

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.

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

#65

Post by pmontra »

bhawks wrote: post #28
PhilipRoman wrote: post #24

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…

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 code run.

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

#66

Post by usrusr »

mort96 wrote: post #52
tsimionescu wrote: post #49

Earlier quoted context omitted.

Because the timing difference is extraordinarily subtle, far too small to measure compared to regular network timing noise.

Noise doesn't protect against that, statistics is a thing. But I think you might overall be right that this requires two colocated processes: the paper talks about how the DMP breaks assumptions made by "the constant-time programming model", and I took this to mean that constant-time algorithms aren't constant-time any more. Reading more closely, I think maybe the issue is that "the constant-time programming model" w…

My attempt at skimming for "what would be needed": controlled input specifically designed to make the process with the keys speculatively fetch or not fetch address lookalikes depending on key bits, and some observer comparing timing either of fetches to canary addresses after the key has or has not triggered a fetch, or observing how the timing of the crypto parts changes with our without canary fetches beforehand. Or perhaps even outside observability from inputs that would either fetch the same canary address twice, or two separate address, depending on key bits?

In any case, the stack of "this could not possibly be workable / but with enough statistics it can, and computers are plenty fast to generate statistically useful case numbers" is truly mindboggling with these attack vectors.

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

#67

Post by sofixa »

eru wrote: post #43
bluetomcat wrote: post #8

Now looking for an affordable M3 Max MBP that should cost less than my car :-)

Here in Singapore, everything that Apple does costs less than any car you could buy.

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&...

2 - https://www.apple.com/sg/shop/buy-mac/mac-studio

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

#68

Post by pmontra »

sofixa wrote: post #64
pmontra wrote: 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.

Yes, but it can be countered by pinning "random-script-from-the-internet.sh" to the untrusted environment. The fork/exec inside bash (or whatever bash is using now) should take care or that, or the kernel itself which is probably a better option. bash + ls -> trusted because ls is in some way marked as trusted, bash + random-script -> untrusted, possibly by default.

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

#69

Post by usrusr »

bhawks wrote: post #21
midtake wrote: 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?

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)…

Is the untrusted code observer able to see cache timing implications of fetches to addresses that the MMU considers off limits for the process? This is what keeps surprising more, it does not align well with what I think I know about processors (not much)

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

#70

Post by shp0ngle »

SuchAnonMuchWow wrote: post #30
tombot wrote: post #3

Actual article https://arstechnica.com/security/2024/03/hackers-can-extract...

actual source of the article: https://gofetch.fail/

The Ars article is arguably more useful than the vuln website, with more added context; it's not just blogspam.
Post reply on HN