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

31–40 of 145 posts

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

#31

Post by amelius »

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

> For cryptographic applications yes.

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

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

#32

Post by amelius »

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?

Perhaps we should do the crypto in constant time, and run all other applications using homomorphic encryption?

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

#33

Post by mort96 »

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?

This isn't speculative execution.

EDIT: The downvotes make no sense. What this bug has in common with Spectre is that it has to do with cache timing. But in Spectre, the cache is affected by speculative execution; with "GoFetch", it's the pre-fetcher pre-fetching things which look like memory addresses. Pre-fetching is not speculative execution.

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

#34

Post by bhawks »

amelius wrote: post #31
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)…

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

Check out https://www.qubes-os.org/ for an operating system that tries to put as many layers of defense as possible between an end user's applications.

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

#35

Post by mort96 »

PhilipRoman wrote: post #24
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?

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…

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

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

#36

Post by tsimionescu »

amelius wrote: post #31
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)…

> 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 this email will be identical.

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

#37

Post by PhilipRoman »

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.

Indeed, the scary thing is that there is no theoretical limit to how sophisticated a side channel attack could be. Imagine all the timing data that could in theory be gathered from html layout engines and css, even without javascript, just by resource loading times.

I would like to salute my shitty ISP for keeping me safe from timing attacks using their unreliable network infrastructure.

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

#38

Post by tsimionescu »

mort96 wrote: post #35
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…

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.

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

#39

Post by Aaargh20318 »

switch007 wrote: post #23
Kluggy wrote: post #16

Earlier quoted context omitted.

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

> 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

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.

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

#40

Post by [deleted] »

mort96 wrote: post #35
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…

OpenSSL is "trusted code". The problem isn't that OpenSSL is doing something nefarious, but that the CPU breaks assumptions it makes about how one can write constant-time algorithms.

[deleted]
Post reply on HN