Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

Post reply on HN
Print view View original

261–270 of 406 posts

Re: Hertzbleed Attack

#261

Post by mr_toad »

MrWiffles wrote: post #2

Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they…

> Are you affected? Very likely.

How long is it likely to take to apply this to cryptographic protocols that people actually use? The protocol they attacked is rather obscure: https://en.wikipedia.org/wiki/Supersingular_isogeny_key_exch...

Re: Hertzbleed Attack

#262

Post by userbinator »

BoppreH wrote: post #122
xoa wrote: post #58

Earlier quoted context omitted.

> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Eh? Doesn't this require an attacker to actually be able to talk to the targeted system? You mention classes of actor ("journalist, human rights activist, etc") that aren't online public service providers or at least perhaps shouldn't be. Private devices connecting out to the greater net are effectively universally behind…

> the attacker does in fact need to be able to get the targeted system to run something somehow Unfortunately that includes Javascript, and now that affects virtually everybody. Speculation: if you can find a Javascript call that uses protected keys, you might be able to extract secrets from that route.

Just like Spectre/Meltdown, it assumes you have an idea where to extract the secrets from, and more importantly what they secure. A string of random bytes is worth nothing to someone who doesn't know what they're the key to.

...and someone who is running JS is probably also running tons of other JS, adding even more noise to what already exists.

Re: Hertzbleed Attack

#263

Post by samstave »

NamTaf wrote: post #240
samstave wrote: post #208

Earlier quoted context omitted.

Quoted post unavailable.

This has almost no similarities to stuxnet. A more analogous hypothetical attack to stuxnet would be if they repeatedly cycled spinning rust drive heads in a certain way to cause the motors to fail and corrupt data, all the while faking the SMART data of the drive to not report drive head parking cycles. Your understanding of either this attack and/or stuxnet is flawed.

Rspndplz.

Defute

Re: Hertzbleed Attack

#264

Post by selcuka »

userbinator wrote: post #258

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

> they relied on so much detailed information about the environment being attacked

A disgruntled, previous employee may easily have access to such information, but nothing else because their credentials had been disabled.

Re: Hertzbleed Attack

#265

Post by hsuduebc2 »

jakogut wrote: post #252
hsuduebc2 wrote: post #247

Earlier quoted context omitted.

I'm not getting the part how disabling turbo boost lowers your cpu performance. It should only significantly increase power consumption right?

Disabling turbo boost/frequency boosting would actually _decrease_ power consumption, as well as performance. The idea with boosting is to allow certain cores to exceed the maximum frequency, so long as certain parameters such as package temp, core temp, and power usage are within certain thresholds. This allows workloads that don't push the entire CPU to its limits to run faster, as the few cores that are in use can…

Thank you for clarification. :)

Re: Hertzbleed Attack

#266

Post by hsuduebc2 »

STRML wrote: post #249
hsuduebc2 wrote: post #247

Earlier quoted context omitted.

I'm not getting the part how disabling turbo boost lowers your cpu performance. It should only significantly increase power consumption right?

Turbo will move the processor above the rated TDP when there is thermal headroom to do so. Turning it off means you'll max out at the rated TDP. Now, TDP used to mean the max power of the chip, but as Intel's process failures left them holding the bag with no significant performance updates to speak of, they started overclocking their chips more and more so they could claim that the new gen was faster than the last.…

Wow. How to they get their score in benchmarks? You can't "temporarily overclock" your cpu for too long right?

Re: Hertzbleed Attack

#267

Post by fijiaarone »

Here’s a simple mitigation — don’t have your encryption depend on 2022 + 23823 being compared to 2022 + 24436.

The idea that a cpu frequency change (based on cpu load) could be detected, and if detected — that it could lead to any useful information by an attacker is laughably preposterous.

The only theoretical vulnerability is if someone in a shared data center was able to gain control over a system on dedicated hardware that had nothing else running on it — exploit some code on it that triggers and expected frequency — open the cage and case, detects the frequency (by turning off all other hardware in the vicinity — meaning you already know which machine it is) and then by exploiting the machine you already control (and have already isolated) you can then physically identify the machine you have exploited.

Re: Hertzbleed Attack

#268

Post by userbinator »

selcuka wrote: post #264
userbinator wrote: post #258

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

> they relied on so much detailed information about the environment being attacked A disgruntled, previous employee may easily have access to such information, but nothing else because their credentials had been disabled.

It also requires having access to continuously "challenge", for many hours, a server which seemingly has no other processing to do but running this one crypto algorithm in an otherwise noise-free environment.

Re: Hertzbleed Attack

#269

Post by kelnos »

userbinator wrote: post #258

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

Same here. I just can't get worked up about these anymore. It was a while before Spectre and Meltdown were fully mitigated in most OSes, and I imagine there are a lot of appliance-like devices out there that aren't fixed and will never get fixed. And yet where's the news of all the active exploits floating around, being used to ruin people's day? Sure, no evidence doesn't mean evidence of nothing, but I think we have a lot more to worry about than stuff like this. Especially given that Hertzbleed's target for their research was SIKE, which... I'd barely heard of it until now.

Re: Hertzbleed Attack

#270

Post by kelnos »

selcuka wrote: post #264
userbinator wrote: post #258

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

> they relied on so much detailed information about the environment being attacked A disgruntled, previous employee may easily have access to such information, but nothing else because their credentials had been disabled.

I think you overestimate what kind of information most employees -- even those who build the software that runs on their servers -- have about their execution environments.
Post reply on HN