Hacker News new | ask | show | jobs
by Kluggy 812 days 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.

2 comments

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

Yes, and now browsers have mitigations which make timing attacks harder. This bug also has a key dependency on being able to trigger a crypto operation in a local process, which isn’t easy to do from a browser sandbox or in general on a Mac.

The angle I’d worry about is something like a password manager, but most of those already have an authentication step and I’d be surprised if they didn’t have rate-limiting.

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.

>It requires local access

What does this mean? All I read is access to user space. Wouldn’t any web browser be enough?