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

221–230 of 406 posts

Re: Hertzbleed Attack

#221

Post by goodpoint »

SilverBirch wrote: post #198
mike_hock wrote: post #117

Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto. The need for constant time should have first class support on the language/compiler…

This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack. Think…

> we don't all run ECC RAM either

...because Intel placed profit above user's needs and choose not to allow ECC on desktops.

Similarly, many other things have been made insecure by plain greed.

Re: Hertzbleed Attack

#222

Post by ziddoap »

CamperBob2 wrote: post #205
nickelpro wrote: post #199

Earlier quoted context omitted.

Yep, and yet everyone in this thread seems to be rushing to kneecap their own performance, for what? My laptop isn't a GKE node. There's a reason this CVE is classified as medium severity

I think the one-dimensional severity classification is part of the problem. If you're running a cloud provider, it's a much bigger deal. Call it "high severity" issue for those use cases. No objection to that, better safe than sorry. Probably 90% of PCs are single-user Windows desktops, though. It's a "nonexistent severity" issue for those use cases... yet we all get to pay.

>. If you're running a cloud provider, it's a much bigger deal. Call it "high severity" issue for those use cases. No objection to that, better safe than sorry.

It's odd, because this agrees with what I wrote, and the parent to your comment says they "fully concur", yet they are arguing that I'm incorrect. I did a poor job in communicating.

As an attempt to better clarify what I wrote: I agree with you that for the vast majority of people this specific attack is a non-issue. But, there are plenty of different timing attacks, and some of those may affect some people. It would follow then that some timing attacks should not be abruptly dismissed simply because it's classified as a timing attack.

However, my initial comment was replying to someone who wrote off the entire class of vulnerabilities, asserting that no timing attack of any variety has been used successfully. I find this a naive approach to vulnerability management. Instead of dismissing all attacks that are classified as timing attacks, vulnerabilities should be assessed for what they can do, the ease of doing it, and the potential impact of a successful attack.

Re: Hertzbleed Attack

#224

Post by bruce343434 »

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 got the same feeling, how does this apply to me?

Re: Hertzbleed Attack

#225

Post by ziddoap »

nickelpro wrote: post #219
ziddoap wrote: post #210

Earlier quoted context omitted.

Not all timing attacks require any sort of privileged access. As one example, OpenSSH had a timing attack where under certain configurations a query for a non-existent user returned faster than an existing user, allowing attackers to enumerate user accounts. I'm not saying this specific attack is something to get worked up over. But, as I have already said, writing off an entire class of vulnerabilities because you t…

I don't blame the researchers, this is specifically against the nonsense discussions that plague this thread and others like it talking about the performance impact on personal computers. These side-channel bugs are minor annoyances, and mostly a problem for cloud providers. I wouldn't want Intel or AMD or anyone else to abandon speculative execution, clock boosting, or any other of the "vulnerable" technologies just…

I agree on almost all fronts.

The person I replied to asserted that all timing attacks are theatre, which I disagree with (and, evidently, poorly communicated my stance). Perhaps they did not mean the entire class of vulnerabilities which rely on some sort of exploitable timing difference, but only those that require privileged (or physical) access. In that case, I still believe it is foolish to completely dismiss them simply for being a 'timing attack' (and therefor theatre), but I also believe it is foolish to blindly follow mitigation recommendations without analysis.

Re: Hertzbleed Attack

#226

Post by mlor »

stingraycharles wrote: post #16

This is probably a naive question, but could this be mitigated by fencing a part of code by some “frequency fence” of some sorts? This is of course a long-term mitigation as it may require compiler support, may affect performance and other threads and whatnot, but I wonder what a proper solution would look like.

I'm curious whether this type of thing would work as well. It sounds like you're suggesting to be able to wrap sections of code in compiler-specific declarations (e.g., UNSAFE blocks in C#) that force the underlying hardware to operate at a constant frequency.

I have PRECISELY no idea whether that is coherent or makes sense. It's just interesting at a glance.

Re: Hertzbleed Attack

#227

Post by gambiting »

goodpoint wrote: post #221
SilverBirch wrote: post #198

Earlier quoted context omitted.

This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack. Think…

> we don't all run ECC RAM either ...because Intel placed profit above user's needs and choose not to allow ECC on desktops. Similarly, many other things have been made insecure by plain greed.

The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).

Re: Hertzbleed Attack

#228

Post by 2OEH8eoCRo0 »

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…

You can configure your CPU to always boost if you're really paranoid. It shouldn't run much hotter since the load doesn't increase, just the frequency.

Re: Hertzbleed Attack

#229

Post by goodpoint »

jfk13 wrote: post #148
candiddevmike wrote: post #25

And yet folks will keep using cloud services and multi tenant offerings until we have regulations forbidding multi tenant computing for sensitive data.

How many people can reliably identify "sensitive data", do you think?

Enough to collect and handle such data in the first place.

Or do you handle data without knowing what it is?

Post reply on HN