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

241–250 of 406 posts

Re: Hertzbleed Attack

#241

Post by Melatonic »

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…

Is that all you need to do? Because many overclockers permanently disable Turbo boost anyways so that they can run a higher clock ratio all the time (cant have turbo occidentally crashing your system once you have really overclocked it a lot). This does not of course disable the low power states for idle or low low load. I probably have Turbo disabled right now!

Re: Hertzbleed Attack

#242

Post by FrostKiwi »

I do wonder, if only the Turbo P-States are what cause the vulnerability. Is relying on Deep C-states for instance an alternative to get power savings? On my server during idle, when cores enter C6, the power savings are at their maximum and no frequency scaling can match that. Why not just rely on that? (Ignoring the loss of turbo boost ofc)

Re: Hertzbleed Attack

#243

Post by sim7c00 »

honestly, i dont think this is some universal remote exploit, despite it being remotely exploitable. under certain circumstances seems a keyword here..

this is incredibly clever and devious, but mostly i think practical locally. since different cpus have different power usage, and systems roll different configurations, id expect the most reliable use case would be for instance to roll a custom os on a confiscated device to learn what power throttling patterns it has related to this kind of attack and then perform that on the systems original installation to decrypt it. (something along those lines). I think, maybe better in a counter example, that it is unlikely that someones online service or personal system would be ever exploited by this. why? because the system runs a lot of threads in general when its being used, making it much harder to predict what measurements mean what. if a system is not idle during the attack, its hard to deduce if timing diffetences are related to the attack or for example just other tasks/threads being executed during the attack.

am i wrong?

Re: Hertzbleed Attack

#244

Post by hinkley »

rictic wrote: post #126
ChrisLomont wrote: post #113

Earlier quoted context omitted.

>fixed-frequency crypto core would be susceptible to the same attack, I also added there are other attacks. Once you are allowing multiple processes to utilize these limited crypto cores, you're gonna leak information. And fixed frequency makes many attacks easier - the attacker no longer has to work through variances in performance due to all the randomness in chips from power and caches and other timing things. >as…

What can an attacker do by knowing how many much queued crypto work there is?

This stuff is complicated. You can still get some timing data by trying to schedule additional cryptographic work on the same core where some sensitive operation is going on, and looking at the delays you get.

Re: Hertzbleed Attack

#245

Post by contravariant »

jabart wrote: post #238
_0w8t wrote: post #204

Earlier quoted context omitted.

When Spectre came it turned out that it was very straightforward to implement the relevant attacks in JS. A script can use workers with shared memory access to monitor execution and get a timer with less than 100ns resolution. As the result the shared memory were disabled. Later under the presumption that relevant issues were mitigated, the shared memory was re-enabled again. So I wonder if the shared memory will be…

My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the…

Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?

Re: Hertzbleed Attack

#246

Post by Rafuino »

jagger27 wrote: post #214
Rafuino wrote: post #172

Why did they wait 2 extra quarters to tell AMD about this?

It probably didn't matter too much since Microsoft and Cloudflare were notified at the same time as Intel. Both of them run AMD hardware in their datacenters. It does seem weird though.

Yeah but I wonder whether the users can tell the vendor under disclosure rules. It is really weird that they didn't tell AMD at the same time!

Re: Hertzbleed Attack

#247

Post by hsuduebc2 »

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…

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

Re: Hertzbleed Attack

#248

Post by throwaway81523 »

I haven't looked at the article but this sounds like a local exploit, right? Those were important in the timesharing era, but with personal computers we temporarily had an era when we didn't have to let hostile code run on our computers. When will we learn that we shouldn't have given that up? Local exploits will never go away, at least on high performance machines.

Re: Hertzbleed Attack

#249

Post by STRML »

hsuduebc2 wrote: post #247
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…

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.

Try turning off Turbo Boost on a 2020 i9 Macbook Pro - you actually get a usable machine with reasonable battery life with it off, instead of the hot toaster with 2hr battery life that Intel gave you. But it'll max at something like 2.2GHz when you paid for just over 4.

Re: Hertzbleed Attack

#250

Post by Terretta »

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…

> So Intel *did* ask for a long embargo…

> … again telling us that there indeed WAS a long embargo placed on this research by Intel.

These are worded as if this wasn’t clear? No guesswork, the article states it plainly:

”We disclosed our findings, together with proof-of-concept code, to Intel, Cloudflare and Microsoft in Q3 2021 and to AMD in Q1 2022. Intel originally requested our findings be held under embargo until May 10, 2022. Later, Intel requested a significant extension of that embargo, and we coordinated with them on publicly disclosing our findings on June 14, 2022.”

Post reply on HN