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

81–90 of 406 posts

Re: Hertzbleed Attack

#81

Post by karussell »

kevingadd wrote: post #56
pyrolistical wrote: post #36

I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?

The frequency change is observable by the whole algorithm taking a different time to run - the algorithm is constant-time, but because the clock speed is changing based on the data, it's not constant-wall-clock-time and you can perform a timing attack.

And also when I set the scaling governor to "performance" (under Linux)? Is the frequency in that case still adjusted based on the data or always "maximum"?

Re: Hertzbleed Attack

#82

Post by minedwiz »

leephillips wrote: post #4

My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?

Oh man the overclocking community would just love it if Intel messed with the power scaling architecture

Re: Hertzbleed Attack

#83

Post by ChrisLomont »

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.

Re: Hertzbleed Attack

#84

Post by Zamicol »

nindalf wrote: post #35
kube-system wrote: post #10

I'm not too much of a cryptography expert. How do I know if I'm using a > constant-time cryptographic library ? Edit: thanks everyone, I just wasn't familiar with the terminology.

All libraries we use are constant time. What’s constant time? Crypto libraries need to do operations to encrypt and decrypt your data. The simple, naive implementation of these operations will work - giving correct input and output. However, a person can time the operation being performed and learn about the key being used. If you’ve deployed on a server and the other person can submit any text they want, whenever th…

>All libraries we use are constant time.

Well, except anything Javascript.

"Node.js’s crypto libraries do not provide constant-time guarantees and, unfortunately, are still at the mercy of the JavaScript GC"

https://cseweb.ucsd.edu/~dstefan/pubs/renner:2018:ct-wasm.pd...

Re: Hertzbleed Attack

#85

Post by velcrovan »

kzrdude wrote: post #75
bob1029 wrote: post #14

Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any m…

You can say the same thing about all of these attacks. That they are tedious ways of collecting data. The problem is that computers can be made to repeat operations, over and over again. Leaking keys fractional bit by bit or what it is. That's why the attack doesn't work against someone's laundry machine - unless it's connected to the internet, that is.

This is the kind of exploit that might legitimately warrant the character-by-character “password slot machine” animation from movies like “War Games” (https://tvtropes.org/pmwiki/pmwiki.php/Main/PasswordSlotMach...)

Re: Hertzbleed Attack

#88

Post by mike_hock »

bob1029 wrote: post #14

Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any m…

> To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time.

That sounds almost trivially easy provided you can afford to buy each and every washing machine on the market so you can measure its power consumption profile for each of its programs.

Re: Hertzbleed Attack

#89

Post by depereo »

gpm wrote: post #15
api wrote: post #3

Earlier quoted context omitted.

> 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.) The most likely to be targeted (and probably easiest to target) systems are probably cloud hosts. This might be an argument for disabling frequency scaling and fixing clock speed on cloud VM hosts or bare metal se…

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

Re: Hertzbleed Attack

#90

Post by yunohn »

jackcook wrote: post #60
pyrolistical wrote: post #36

I don't get it. Is this only a problem for platforms that can read the current CPU frequency? Does this mean platforms such as JavaScript in the browser are unable to exploit this? Ditto for WebAssembly? If you don't give it the CPU frequency and don't give it the ability to make a syscall for it, then its unaffected? Is the longer term fix then to make reading of any compute metrics a privileged operation?

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 those websites to be public to train the model first? I’m not convinced that detecting porn access is particularly malicious, but I acknowledge that it is illegal in some places.

Post reply on HN