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

61–70 of 406 posts

Re: Hertzbleed Attack

#61

Post by jessermeyer »

1MachineElf wrote: post #48

Interesting that the mitigation is to turn off Turbo/Precision Boost. Four or five years ago there was an an article submitted here (I wish I could find it) about a developer who keeps a machine with Turbo Boost disabled specifically because it seemed to interfere with their performance testing. By keeping it disabled they were able to eliminate a number of factors that prevented them from getting consistent results.…

Yes, this is a common technique in optimization. With frequency scaling enabled, a profiled function may have more than one hot region, implying 'hot' and 'code' code paths, but are really just manifestations of CPU speed being non-constant.

Re: Hertzbleed Attack

#62

Post by night-rider »

So this can be used on so called ‘airgapped’ devices, but what if you house the machine in a giant Faraday cage to prevent this? Maybe a little paranoid, but if your threat model requires it, then surely Faraday cages would make sense no?

Re: Hertzbleed Attack

#63

Post by rocqua »

Isn't this sort of a stand-in for power draw side-channel analysis? I guess it is cool that you can do it purely from software rather than needing physical access.

Re: Hertzbleed Attack

#64

Post by alanh »

teraflop wrote: post #12
leephillips wrote: post #4

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

Unfortunately, trying to defeat side-channel attacks by adding random noise usually only increases the number of samples required to extract information, rather than preventing the attack entirely. (You can blame the central limit theorem for this.)

100% correct

Re: Hertzbleed Attack

#65

Post by tester756 »

leephillips wrote: post #4

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

How about returning the same frequency to OS every and change it every 10sec?

2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 2.9 3.2 3.2 3.2 3.2 3.2 3.2 3.2 3.2 2.8 2.8 2.8 2.8 2.8 2.8 2.8 2.8 2.8

totally fake value

Re: Hertzbleed Attack

#66

Post by wmf »

jessermeyer wrote: post #47
api wrote: post #3

Earlier quoted context omitted.

> 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.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…

There's so much variation (read, noise) intrinsic to response times for network requests to be satisfied on most cloud hosts anyway that I'm very skeptical about any practical attacks being made in the short term.

For one request, yes. For statistical analysis of many requests, no. People keep extracting secrets from very noisy and weak signals.

Re: Hertzbleed Attack

#68

Post by planb »

Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server running real life workloads, I am extremely skeptical. How much samples are needed to get anything useful? And wouldn't the time required to acquire these samples be longer than the time required to detect the attack (or even all keys to be shifted)?

Re: Hertzbleed Attack

#69

Post by rdpintqogeogsaa »

What's the impact on AES-NI specifically? If hardware AES is impacted and no microcode updates are coming, this would be bad news.

Assuming ChaPoly needs expensive masking mitigations and AES-NI is safe, ChaPoly just became a lot less attractive, too.

Re: Hertzbleed Attack

#70

Post by yunohn »

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…

> > Why did Intel ask for a long embargo, considering they are not deploying patches?

> > Ask Intel.

Indeed, I really found this unnecessarily snarky on their part. I don’t think Intel was acting in bad faith.

In my experience, security researchers are very /particular/. They like telling everyone that no matter what you do, you are vulnerable for umpteen reasons, whether practical or not.

Post reply on HN