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

[arQon]

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

The thing is, there are a LOT of "seldom-changed keys" out there. The monthly/etc password changes that clueless IT depts insist on are actually security theater that does more harm than good, and NIST has advocated against them strongly for a very long time now.

Similarly, while most encryption methods will let you rewrap a key with a new passphrase, the key itself remains constant, for obvious reasons.

Luckily, this does seem very much like a purely-academic "threat" right now, and unlikely to be advanceable into something practical, but we'll have to see how things go.

[justinkb]

I have serious doubts as to the actual practical exploitability of this. Also, on VMs this should be less of an issue, not more, as is being suggested above me? On VMs there is less correlation between power usages and the happenings inside the specific VM, since whatever is hosting the VM is presumably doing lots of other things too.

[F.Ultra]

This should mainly affect servers with VMs again, right?

any other software/user on your system can utilize exploits like this, a full VM is not required but of course they will be far more susceptible to this since they be default are other users running software on your system.

[carewolf]

If your CPU is actually locked to full boost frequency then you aren't affected if I understand right. If it scales up dynamically dependent on load (even if it can boost forever), then you're affected. But this seems even more far fetched than all the the previous vulns so I'd expect impact to be limited. So much so that Intel won't even release a "fix".

I don't think it will be affected by boost either unless constrained by a power limit or thermal envelope. Boosting based on just running CPU bound code for full timeslots. It isn't effected by what instructions are used. To be able to measure the minute differences in power consumption based on variables, you need to be scaling based on power consumption.

[binarybanana]

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

If your CPU is actually locked to full boost frequency then you aren't affected if I understand right. If it scales up dynamically dependent on load (even if it can boost forever), then you're affected. But this seems even more far fetched than all the the previous vulns so I'd expect impact to be limited. So much so that Intel won't even release a "fix".

[bob l'eponge]

Hertzbleed ?

Sounds like a wounded rental car.

So check your mirrors for side channel attacks, dude !

[Termy]

This should mainly affect servers with VMs again, right?

[danielp]

AMD's security advisory isn't yet public but it's known at least Zen 2 and Zen 3 are affected.

AMD's security advisory is public:

https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1038

[danielp]

My understanding is openssl and libressl use methods to prevent these kind of attacks. Are these findings finding that they need rethought, hardened further or is do other implementations need hardened?

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/frequency-throttling-side-channel-guidance.html

Intel's guidance states that mitigating the underlying power side-channel is sufficient to prevent the Hertzbleed attack. According to the openssl security policy:

Certain threats are currently considered outside of the scope of the OpenSSL threat model. Accordingly, we do not consider OpenSSL secure against the following classes of attacks:

[...]

• physical observation side channels (e.g. power consumption, EM emissions, etc)

I didn't see any mention of power side-channel resistance in a cursory glance at the OpenSSL code, so it might be vulnerable.

[intelfx]

"in order to mitigate the Hertzbleed vulnerability, we're disabling cpufreq by default"