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

211–220 of 406 posts

Re: Hertzbleed Attack

#211

Post by gpm »

sofixa wrote: post #37
gpm wrote: post #15

Earlier quoted context omitted.

> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.

Depends on your workload, spot batch jobs would run at sustained maximum.

Absolutely, my observation is in a way that "most workloads don't seem (to me) to be like that".

The number of servers serving interactive queries (frontends, rest api servers, databases, etc) seems (to me) to greatly outnumber the number of batch jobs, and I've always seen those intentionally "over" provisioning CPU because otherwise you get latency issues if load increases at all.

I don't actually know that cloud providers don't either have some clever way around this (e.g. spending spare CPU cycles on some other form of work), or that it isn't the typical usage pattern, but I strongly suspect it.

Re: Hertzbleed Attack

#212

Post by frankus »

kzrdude wrote: post #87
halfmatthalfcat wrote: post #8

At first I thought it had something to do with the company Hertz...

It's just the German dub of Heartbleed that finally showed up. The cast of voices is dull though

I’ve often wondered if choosing Hertz as the name for “cycles per second” was some kind of scientific dad joke since 1 Hz ≈ human heart rate.

Re: Hertzbleed Attack

#213

Post by nickelpro »

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.

Fully concur, although now that I've read some of the white paper some of this doesn't even appear to be a real issue? Like the claimed "remote" attacks against, "Cloudflare’s Interoperable Reusable Cryptographic Library (CIRCL) [28], written in Go, and Microsoft’s PQCrypto-SIDH [65], written in C ... [are] meant to run in constant time"

But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time?

Re: Hertzbleed Attack

#214

Post by jagger27 »

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.

Re: Hertzbleed Attack

#215

Post by neurostimulant »

xoa wrote: post #155
BoppreH wrote: post #122

Earlier quoted context omitted.

> 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.

OK, but can you walk me through the threat model here? This isn't a rhetorical question, it's easy to see how servers in general and shared hosting, colocated VMs etc in particularly might theoretically face a threat here, I'm just trying to get a better understanding of how GP would be correct for end user devices. The individual in question on the smartphone or computer specifically chooses to initiate a connection…

Many password managers are using end-to-end encryption and have browser extensions written in js. It would be bad if hertzbleed can be used to extract keys used by those password manager extensions.

Re: Hertzbleed Attack

#216

Post by throwawaylinux »

mlyle wrote: post #136
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…

> Why do we never get proactive defense ... The need for constant time should have... We got proactive constant time on a lot of cryptographic operations. The problem is, it's not constant power.. and DFS provides a window by which you can make remote power measurements.

That wasn't proactive it was in response to earlier timing analysis attacks.

Re: Hertzbleed Attack

#217

Post by kzrdude »

frankus wrote: post #212
kzrdude wrote: post #87

Earlier quoted context omitted.

It's just the German dub of Heartbleed that finally showed up. The cast of voices is dull though

I’ve often wondered if choosing Hertz as the name for “cycles per second” was some kind of scientific dad joke since 1 Hz ≈ human heart rate.

It has a certain beauty to it! Confusingly enough Herz and Hertz are homophones but the former is the spelling used for heart. However it's possible the name Hertz is derived from an arcahic spelling for heart.

Re: Hertzbleed Attack

#218

Post by href »

depereo wrote: post #89
gpm wrote: post #15

Earlier quoted context omitted.

> since those tend to run at a sustained max anyway Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.

I am on the cloud provider side; we would sometimes limit the upper and lower range of frequency but completely disabling scaling would be very unusual.

Same. Our compute hosts are generally not using 100% of their cores at all time.

There’s computes that are not full, computes that run rather diverse tenants, and even the fully utilized computes responsible for CPU optimized VMs have enough variance in their workload for frequency scaling to occur.

Re: Hertzbleed Attack

#219

Post by nickelpro »

ziddoap wrote: post #210
nickelpro wrote: post #193

Earlier quoted context omitted.

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot.…

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 because their unsafe in specific application spaces, which seems to be what half of HN starts advocating for whenever this stuff comes up.

An application bug like OpenSSH is a completely separate spiritually from the hardware bugs that inspire these mitigation discussions.

Re: Hertzbleed Attack

#220

Post by AlexCoventry »

yunohn wrote: post #70
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.

If they didn't tell you about the risks and you got hacked, you'd also be asking why.
Post reply on HN