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

101–110 of 406 posts

Re: Hertzbleed Attack

#101

Post by jackcook »

yunohn wrote: post #90
jackcook wrote: post #60

Earlier quoted context omitted.

You can pull off attacks like this from JavaScript by repeatedly recording the time and training a machine learning model on traces of instruction throughput over time, which my group did in a recent paper: https://jackcook.github.io/bigger-fish/

Could you elaborate on this attack? It’s an interesting read, but I’m curious about practicality. How would you ensure that the user loads your malicious script, and has a running web worker for it? I see that you trained it on 100 websites. Would you need to retrain for every new version deployed or different paths with varying content? If your intention is to detect sensitive website accesses, wouldn’t you need tho…

You'd just need to put the script on any webpage the user might access and leave open, such as Google, or Facebook, or whatever. The attack isn't specific to JavaScript, so really you could put this in a desktop app too, think Slack, Spotify, etc. Any app or website that you know the target user is likely to open. CDNs are also a great target.

We evaluated on 100 websites as a proof of concept, but we also included experiments in an "open world" setup where the classifier has to predict whether the activity is from one of 100 sensitive websites, or whether it's none of them, and found that it's still very accurate in that more realistic setup. You would need to retrain to identify more websites outside of your set of 100.

The websites would need to be public, which is basically the same limitation as hertzbleed, since they need to know what they're looking for in order to identify an activity. Some use cases with this limitation aren't too hard to imagine: maybe you're in a country that bans access to major Western news sites but you're evading censorship with a VPN.

Re: Hertzbleed Attack

#102

Post by sandworm101 »

snowwrestler wrote: post #98
sandworm101 wrote: post #96

Seems like the simplest way to mitigate is to randomly throw some junk at the problem. Some random cypto code, some random no-purpose cryptographic calculations, should prevent any listener from gaining any useful information. It shouldn't take much, a single-digit percentage increase during cypto functions would be enough imho.

Essentially, a computational time salt.

There are a dozen names for it. In the intelligence world, if you know that the enemy is listening on an unencrypted communications pipe, but you cannot afford to stop using that pipe, you throw random junk down the pipe until they cannot tell real from fake.

Re: Hertzbleed Attack

#103

Post by bayindirh »

mackmgg wrote: post #39
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've always turned off Turbo Boost on my Intel laptops anyway, because of the heat/battery hit. If I was doing something that I really wanted the extra speed and I was plugged in, I would turn it back on for that task, but I never really felt I was missing anything by having it off. Considering how easy it is to turn on/off (on macOS at least I used Turbo Boost Switcher which added a button in the menu bar to toggle…

Turbo Boost is not something you can reliably kick in any load spike due to its operation being constrained by the thread and thermal load of the CPU. Also, it's affected by the CPU instructions you're already running. AVX family is esp. power-heavy and thermal-heavy.

Re: Hertzbleed Attack

#104

Post by tux3 »

ChrisLomont wrote: post #83
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.

One or two cores for crypto would likely be susceptible to the same attacks, unless you don't let any user (or kernel) programs run crypto on those cores, making them useless. Any resource that needs scheduled will likely be attackable - either by timing on context switches, or flooding the resource with users and measuring things, and so on. Likely any scheduling method for those resources can leak information.

I don't see how a fixed-frequency crypto core would be susceptible to the same attack, assuming proper constant-time cryto code.

This attack exploits the fact that cycles are not constant time, so although crypto primitives are constant in terms of cycle, due to DVFS they're not really constant in terms of time.

If the crypto core doesn't have DVFS and runs constant-cycle crypto, it doesn't matter that the core is contended and that you can measure the contention. You'll be measuring how many people are using the resource, but that won't tell you anything about the secret data, just about how much data there is.

Re: Hertzbleed Attack

#105

Post by Sephr »

We need an industry-wide effort for coordination between cryptography library owners & device/chip vendors to ensure the use of constant CPU frequencies during cryptographic operations.

It's odd that the authors haven't chosen to initiate this themselves, as it seems like the proper solution to this vulnerability.

Re: Hertzbleed Attack

#106

Post by willcipriano »

> This means that, on modern processors, the same program can run at a different CPU frequency (and therefore take a different wall time) when computing, for example, 2022 + 23823 compared to 2022 + 24436.

I'm a layman when it comes to things this low level however, I always assumed that different addition inputs would take different amounts of wall time, but looking it up it turns out that in theory I was wrong, but I guess I'm actually correct. ¯\_(ツ)_/¯

Re: Hertzbleed Attack

#107

Post by jl6 »

Assume you’re a tenant on a cloud service provider and you don’t care about power consumption… can you mitigate this by running a process with a busy loop that forces the CPU into max frequency at all times, with `nice` set to run it at lower priority than your actual workload?

Re: Hertzbleed Attack

#108

Post by ChrisLomont »

hgomersall wrote: post #100
ChrisLomont wrote: post #83

Earlier quoted context omitted.

One or two cores for crypto would likely be susceptible to the same attacks, unless you don't let any user (or kernel) programs run crypto on those cores, making them useless. Any resource that needs scheduled will likely be attackable - either by timing on context switches, or flooding the resource with users and measuring things, and so on. Likely any scheduling method for those resources can leak information.

Presumably you can schedule only on non-information-leaking-boundaries with very high level APIs?

>non-information-leaking-boundaries

Every one of the recent leaking boundaries were assumed to be non-leaking. You cannot just inject "non-leaking" into a statement and assume that solves anything.

Re: Hertzbleed Attack

#109

Post by nequo »

rocqua wrote: post #94
nequo wrote: post #86

Naive question: Would another possible defense be for the kernel to introduce a small random delay in the task scheduler?

You would need to block access to high-resolution time sources. Because all an attacker needs is accurate measurement of how long code ran.

> Because all an attacker needs is accurate measurement of how long code ran.

So would it thwart the attack if the kernel added a random delay to the execution time?

Post reply on HN