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

371–380 of 406 posts

Re: Hertzbleed Attack

#371

Post by ericpauley »

mike_hearn wrote: post #344
theicfire wrote: post #315

Hmm, it feels like Intel/AMD are ducking and just hoping that the implications of this are not large. Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/... The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack…

What you're seeing here is a collision between academic cryptography culture and real world engineering culture. In particular, the word "practical" has very different meanings in those two worlds, hence the discrepancy. In engineering, the word "practical" has an expansive definition that takes into account end goals, likely costs, rewards and risks of getting there, whether better approaches exist and so on. In aca…

Interestingly, AWS takes no such actions against massive scans of infrastructure. One can acquire millions of cloud servers in search of co-residency without action being taken.

Re: Hertzbleed Attack

#372

Post by STRML »

hsuduebc2 wrote: post #266
STRML wrote: post #249

Earlier quoted context omitted.

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?

Correct. This makes benchmarks, at least on thermally limited machines like laptops, very unreliable. High-quality review sites like notebookcheck spend a lot of time dealing with this by doing prolonged benchmarks and measuring thermals.

And there's an honest question to ask: how do you use your computer? If you're just browsing the web 95% of the time and occasionally opening Word/Excel, then short bursts of high power when you need it is perfect. But if you run longer tasks like many programmers or artists do, these machines simply fall down in sustained use.

This is one reason why the M1/M2 architecture has been such a revelation for professionals who primarily work on laptops. It can run full-bore for hours, because the lower-end chips (which are faster than any Intel released at the time) barely hit 10W at max load.

Re: Hertzbleed Attack

#373

Post by cestith »

Proven wrote: post #346
hulitu wrote: post #331

Earlier quoted context omitted.

> So Intel did ask for a long embargo, then apparently did nothing about it. It was not for them but for their 3 letter customers. 0 day unpatched for 1 year, what can be better than that ?

Doesn't make any sense - there's no benefit to Intel (why would anyone order more CPUs?) and there's much more downside from all other customers.

It gives certain customers time to mitigate - and certain others time to exploit - the issue before the embargo is lifted. It maintains the customer/vendor relationship. It also allows Intel, even if current products are still impacted, a head start on R&D for future products before disclosure. Remember Intel also has their own Linux, has their own compiler suite, and directly supports development of Linux and Windows (and probably macOS for Apple) for their industry partners. So they could have been working on figuring out software mitigations during that time which they can now share.

Re: Hertzbleed Attack

#374

Post by avianes »

staticassertion wrote: post #369
dkbrk wrote: post #209

I think it's worth noting that the main attack described in the paper, against SIKE, depends on exploiting some behavior peculiar to that particular algorithm (what the paper calls "anomalous 0s"): > The attacker simultaneously sends n requests with a challenge ciphertext meant to trigger an anomalous 0 and measures the time t it takes to receive responses for all no requests. When an anomalous 0 is triggered, power…

I think SIKE was just chosen because of its relevance, not because it has any particular issues that make it more susceptible. I'd be curious to hear from an expert on this.

SIKE is definitely not the most widely used cryptographic algorithm. And as the paper points out:

> In our attack, we show that, when provided with a specially-crafted input, SIKE’s decapsulation algorithm produces anomalous 0 values that depend on single bits of the key.

It was clearly selected for this property. The attack allows to determines the number of 0s and 1s in words processed by an algorithm, so they chose an algorithm that has specific data outcomes which will produce a measurable power effect.

Re: Hertzbleed Attack

#375

Post by gralx »

Terretta wrote: post #250
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 unti…

You missed this part:

> Only mentioning this here just in case the PR spin doctors threaten the researchers into removing mention of Intel on this one.

Re: Hertzbleed Attack

#376

Post by _8j50 »

zgs wrote: post #364
_8j50 wrote: post #360

Can't intel and amd just change how long a core stays at a turbo frequency to mitigate this? I.e.: if it scales up by 1hz, it can't scale down by that much until N number of cycles.

This would add noise to the measurements which should cause an exploit to take longer but it wouldn't prevent the exploit.

Pardon my ignorance but why wouldn't sufficient noise make it practically impossible to timing attacks. Very short secret material being processed multiple times?

Re: Hertzbleed Attack

#377

Post by orblivion »

IfOnlyYouKnew wrote: post #316
orblivion wrote: post #182

As I've said before, these announcements could benefit from better "action items" or "TLDR" for the average person with other problems to think about. What libraries are affected, what do I need to upgrade exactly, on Ubuntu, etc etc. And I'm guessing this is intended to reach those people (among others) given the effort they put into the graphics, etc. In this case. "Am I affected?" "Likely, yes. It's on all the CPU…

There really isn't anything for the "average person" to do here, who wouldn't understand any of your questions, either (the library? The one with all the dirty books?)

What about the average reasonably computer savvy person?

Also "don't worry about it" or "there's nothing you can do for now" is an answer.

Re: Hertzbleed Attack

#379

Post by orblivion »

orblivion wrote: post #182

As I've said before, these announcements could benefit from better "action items" or "TLDR" for the average person with other problems to think about. What libraries are affected, what do I need to upgrade exactly, on Ubuntu, etc etc. And I'm guessing this is intended to reach those people (among others) given the effort they put into the graphics, etc. In this case. "Am I affected?" "Likely, yes. It's on all the CPU…

I'm sorry, sometimes (often) it's my reading comprehension. The answer I was looking for was in the first f-ing paragraph. (And I checked archive.org, it was there yesterday)

"In the worst case, these attacks can allow an attacker to extract cryptographic keys from remote servers that were previously believed to be secure."

I'll probably have more to complain about the messaging when a fix comes out, but for now mea culpa.

Re: Hertzbleed Attack

#380

Post by UncleMeat »

xurukefi wrote: post #326
hinkley wrote: post #49

I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.

Unfortunately, side-channel attacks like this (or like Meltdown, Spectre, TLBleed, Foreshadow, etc...) only have negligible real-world impact. They are very interesting from a theoretical point of view, but are usually totally impractical for a plethora of reasons. Therefore, chip designers aren't really pressured into thinking about new chip designs. The sad reality is that something like Log4Shell, which is super b…

I think that this is shortsighted. It is a new area and there is a lot of work improving the effectiveness of these things. If somebody told me that ROP was totally impractical for a plethora of reasons when it was first proposed, I would have believed them. Now, we've got completely automated tools to generate ROP chains without hardly any access to a binary whatsoever.

These sorts of attacks will get more sophisticated.

Side channels through miss-speculation also have a fun property of being virtually undetectable since the problematic code never actually executes. This is attractive for very powerful actors who might want to spend the extra effort for the covert attack even if there are simpler exploits to actually launch.

Post reply on HN