Hertzbleed Disclosed As New Family Of Side-Channel Attacks Affecting Intel + AMD

[phoronix]

Phoronix: Hertzbleed Attack Disclosed As New Family Of Side-Channel Attacks Affecting Intel & AMD

Hertzbleed has been made public today as a new family of side-channel attacks making use of frequency side channels. Both Intel and AMD have issued security advisories as a result...

https://www.phoronix.com/scan.php?page=news_item&px=Hertzbleed

[gururise]

Damn, so encrypted communications and transactions are potentially compromised unless one disables turbo-boost?

[ddriver]

This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436.

So? We run programs for their output, not for their wall time?

Executing a program on a modern cpu is not ever remotely in the realm of deterministic in timing. A single cache miss can delay by several to several dozens of clocks. And cpu frequencies have been wildly varying for over a decade now...

You cant get deterministic guarantees even on a 32 bit mcus that are intended for high performance real time applications. You need something even more rudimentary than that in order to be able to execute a program in exactly the same amount of time you can logically compute it should, fixed clocks, asic or fpga logic.

I obviously don't know the technical details of the actual exploit. It just seems a totally bad idea to rely on such a metric to be persistent to begin with.

[phoron]

ddriver. Yes, it sound too theoretical to me too. But I think it's just because I'm not expert. It's over my head but the idea is that the attacker chooses part of the data (like the 23823 and 24436 in the example, and from the difference in time it observes can eventually deduce the rest of the data (2022 in the example). So in the end they can extract the key.

On one hand it seems far fetched, on the other it's like Monte Carlo algorithms or so, that repeating many times some imperfect method you can finally find the solution. The key they are guessing is not (fully) random, they're related to known public keys, so that may help discern something (maybe, or maybe they're symmetric keys?).

I read somewhere Intel is saying the attack is scientifically interesting, but practically not too useful (though of course Intel is an interested party). They say it's hard to achieve outside of lab conditions (because of what you said, cache miss, concurrent processes the attacker doesn't control....). But I guess sophisticated attackers have ways to counter all that noise.

[birdie]

Damn, so encrypted communications and transactions are potentially compromised unless one disables turbo-boost?

Not just turbo boost, dynamic CPU frequency scaling from what I've understood. This one is so extremely difficult to exploit, it's just worth forgetting altogether. It also requires a system where only a crypto algo is running which is a rarity nowadays. I might be totally wrong - hopefully someone with more knowledge will chime in.

[ddriver]

If they are throwing that wall time issue in the summary, it should come with some context. What relies on that value being consistent? How is it even remotely possible for it to be consistent?

And if we narrow the scope to some scenario where you are only issuing single clock instructions on register operands - everything is there and is guaranteed to execute in a single clock, and you are guaranteed no cache misses, and you are guaranteed to not have the thread execution suspended by the os or by a hardware interrupt. Oh and ignore scheduling and out of order execution altogether...

Even in that super niche scenario, you could still count persistently via the actual clock cycles counter if you care about consistency that much. Then your count will be independent from the actual running clock speed.

Maybe someone can elaborate the actual reasons?

[Guest]

The one time where tweaking my system for gaming actually improves security I usually disable any kind of frequency scaling and lock it to a multiplier, along with using performance governors/Ultimate Power Plan.

The problem seems to be with the CPU changing it's frequency with certain conditions, but it would sound like disabling scaling altogether would prevent that?

[carewolf]

I guess that only affect laptops? My desktop has enough cooling to run boosted all the time on all cores

[mlau]

I read a bit of the PoC code:
- it works apparently best when the crypto stuff to be sniffed is the only running task. Windows users should be immune by virtue of the OS being a resource hog
- It needs root otherwise it can't read the RAPL (energy monitor) registers.
- It's not fast.

I can certainly see a patient attacker using this to exfiltrate seldom-changed keys.

[Slartifartblast]

Hertzbleed ?

Sounds like a wounded rental car.