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

201–210 of 406 posts

Re: Hertzbleed Attack

#201

Post by abiro »

matthewdgreen wrote: post #26
teraflop wrote: post #12

Earlier quoted context omitted.

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

This is not entirely true. Or rather: it is true when the countermeasure is to add random delays to pad out overall timing, since one can simply collect more samples to obtain an average. And that may be what the OP is suggesting: just scale the frequency to random levels that are not quite the pre-programmed ones, which is very similar to adding random delays. (In practice this might actually work well enough to def…

How about making operations constant time in application code by picking an upper bound which is acceptable for the application, but that is certainly longer than the actual CPU computation and then waiting until the upper bound to return the result?

Eg. my app is performing digital signatures and I'm sure that they take <1ms CPU time, but performing digital signatures in 10ms is acceptable for my application, so when I perform a signature I measure the CPU time elapsed, say 0.5ms and then wait for 9.5ms.

Re: Hertzbleed Attack

#202

Post by samstave »

ancientsofmumu wrote: post #152

This paper relies on Turbo P-states, where they measure the oscillation when that is active; it is not measuring general SpeedStep (OS software controlled) as some seem to have taken away from it. Turbo state is the HWP (hardware P-state controlled) layer above SpeedStep; turning off Turbo in the BIOS still fully allows OS controlled SpeedStep P-states to function, it just disables the hardware level bursting P-state…

No post body was provided.

Re: Hertzbleed Attack

#203

Post by codeulike »

This reminds me of: In the 90s I rememebr hearing a story about someone hacking a supposedly 'impossible' remote machine for a competition - they did it by analysing the response times and using that info to derive the key - at the time, a novel approach. Can anyone remember the story I must be dimly remembering?

Re: Hertzbleed Attack

#204

Post by _0w8t »

bobkazamakis wrote: post #147
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.

> 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. Debatable -- not because of the goofballs who insist on never running javascript, but because it doesn't have the necessary clock precision available.

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 disabled again as it may allow to monitor frequency changes.

Re: Hertzbleed Attack

#205

Post by CamperBob2 »

nickelpro wrote: post #199
Syonyk wrote: post #196

Earlier quoted context omitted.

> 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. And then you put 'mitigations=off' in your kernel command line and go on your way. I do it for all my BOINC compute nodes, because they literally have nothing sensitive on them. But remember, L1TF/Foreshadow could reach across virtual machine bo…

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.

Re: Hertzbleed Attack

#206

Post by drvdevd »

abiro wrote: post #192

Which ARM processors could be affected? Can't find an overview of ARM processors that implement frequency scaling.

I’m wondering the same thing but I’m curious if the heterogeneous nature of modern ARM processors is essentially equivalent- if you can get the same crypto primitive to run first on a P-core and then an E-core, can you measure the difference for a similar effect?

Re: Hertzbleed Attack

#207

Post by omginternets »

samstave wrote: post #202
ancientsofmumu wrote: post #152

This paper relies on Turbo P-states, where they measure the oscillation when that is active; it is not measuring general SpeedStep (OS software controlled) as some seem to have taken away from it. Turbo state is the HWP (hardware P-state controlled) layer above SpeedStep; turning off Turbo in the BIOS still fully allows OS controlled SpeedStep P-states to function, it just disables the hardware level bursting P-state…

Quoted post unavailable.

Could you elaborate?

Re: Hertzbleed Attack

#209

Post by dkbrk »

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 decreases, frequency increases, SIKE decapsulation executes faster, and t should be smaller. Based on the observed t and the previously recovered secret key bits, the attacker can infer the value of the target bit, then repeat the attack for the next bit.

While any leakage of information can in be exploited in principle, it might be that this technique is impractical against a target which doesn't exhibit some sort of behavior that facilitates it.

Re: Hertzbleed Attack

#210

Post by ziddoap »

nickelpro wrote: post #193
ziddoap wrote: post #181

Earlier quoted context omitted.

There are several (dozens) of papers showing the practicality of various timing attacks written by highly respected academics. Just because you haven't stumbled across an attack in the wild one does not somehow invalidate that there are practical attacks. Do you expect those who do carry out a successful attack to email you and let you know of their success? Or perhaps you think they'll exploit someone, and follow it…

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 think it's all theatre is naive. Weighing each exploit against your attack surface, risks, and risk tolerance is not.

>It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed.

Blaming researchers for security theatre when it is the organizations which are not doing their due diligence is, at least to me, a weird way to look at things.

Post reply on HN