Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

311–320 of 406 posts

Re: Hertzbleed Attack

#312
Can't wait until 2050 when all of our computers are bogged down with energy hungry security chips and processors that barely get any real work done because the security arms race demands ever increasing resources...

Re: Hertzbleed Attack

#313
post #49

I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.

This transition has already begun and is to large extent already usable on many platforms. Macs have secure enclave, Android has Trusty and Strongbox, Intel TPM, ARM Trustzone, etc. Some of these are just implemented as VMs on same core though, so could in theory be vulnerable to same type of attack.

Re: Hertzbleed Attack

#314

Earlier quoted context omitted.

Being unnecessarily cryptic and sounding like a crackpot while calling everyone else out for being uninformed is generally unlikely to get you support on Hacker News.

Quoted post unavailable.

Sam: (1) you can't do this; (2) you know you can't do this; (3) do you want us to ban you? because I don't want to ban you but your recent posts are way over the line; (4) I've put the rate limit back on your account; (5) please stop.

Re: Hertzbleed Attack

#315
Hmm, it feels like Intel/AMD are ducking and just hoping that the implications of this are not large.

Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/...

The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack is not practical.

They then bring the researchers and ask them the same question. The researchers say that the attack is very practical because it only takes.. a few hours or days to execute the attack. Here's the specific part: https://youtu.be/BiRPr839dSU?t=1476

Instead of chatting more about this discrepancy they just ignore it and ask the researches how they feel about their new popularity.

From what I can tell from the advisory from Intel, it's simply that people should understand the attack and mitigate it in software. It's very vague. The specifics (i.e. a list of example popular programs that are vulnerable) seem entirely missing.

Re: Hertzbleed Attack

#316

As I've said before, these announcements could benefit from better "action items" or "TLDR" for the average person with other problems to think about. What libraries are affected, what do I need to upgrade exactly, on Ubuntu, etc etc. And I'm guessing this is intended to reach those people (among others) given the effort they put into the graphics, etc. In this case. "Am I affected?" "Likely, yes. It's on all the CPU…

There really isn't anything for the "average person" to do here, who wouldn't understand any of your questions, either (the library? The one with all the dirty books?)

Re: Hertzbleed Attack

#317
post #9

My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?

Any noise strong enough to have a good chance of hiding the signal would completely defeat the benefit of having dynamic frequency scaling in the first place, I think.

What if you discretized the allowed frequencies and linked the rate at which the cpu could switch?

Re: Hertzbleed Attack

#318

Is it not possible to add noise by running other processes in parallel that will also cause frequency boosts to occur and colour the results? Bauscilaly the mitigation is to disable boost, but instead boosting more often or boosting in a controlled way (with another process triggering it) should so help mitigate.... That said if it was that trivial, surely intel or someone would suggest it.

Noise helps to increase the difficulty, but with a large enough sample size you can statistically exclude it, greatly simplified but essentially by doing X-avg(all X).

Imagine you do the above bit for bit. So first you sample 1M times to find the baseline, then flip one bit and sample another 1M times to see if any deviations, and so on.

There is also the chance of your PRNG being predictable, so attacker can predict what noise will be generated if they have seen enough of it.

Re: Hertzbleed Attack

#319

Earlier quoted context omitted.

The exploit comes from a hacked server, a bad ad, social engineering, etc. As for the attack, imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data. This might sound very theoretical, but modern OS'es (and password managers) have lots of keys like that. There's…

> imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data. Don't you need precise clocks for this in JS? The ones that were disabled in browsers after Meltdown/Spectre.

A lot of that has since been rolled back as different mitigations have been deployed against Spectre.

Re: Hertzbleed Attack

#320
post #314

Earlier quoted context omitted.

Quoted post unavailable.

Sam: (1) you can't do this; (2) you know you can't do this; (3) do you want us to ban you? because I don't want to ban you but your recent posts are way over the line; (4) I've put the rate limit back on your account; (5) please stop.

Apologies Dang.
Post reply on HN