4 ms·

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 un

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?

advisedwang 4y ago
> Is this only a problem for platforms that can read the current CPU frequency? No, it just takes measuring the total wall-clock time of the relevant processing to exploit this.
kevingadd 4y ago
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.
- karussell 4y ago
  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"?
  - adrian_b 4y ago
    With the performance governor, the clock frequency is continuously adjusted between the "base frequency" and the "maximum turbo frequency", e.g. between 3.7 GHz and 4.8 GHz, for my computer. With the powersave governor, the clock frequency is continuously adjusted between a frequency much lower than the "base frequency", and also the "maximum turbo frequency", e.g. between 2.2 GHz and 4.8 GHz, for my computer.
- pyrolistical 4y ago
  Haha so constant time algorithm isn’t constant time
  - jaza 4y ago
    Time itself isn't constant, so arguably a constant time algorithm is an oxymoron! But that's a whole 'nother topic.
jackcook 4y ago
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/ https://jackcook.github.io/bigger-fish/
- yunohn 4y ago
  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.
  - jackcook 4y ago
    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.
    - yunohn 4y ago
      I’m a little confused about your attack vector - how feasible would you reckon it is to place such a malicious script on the largest public websites in existence, versus just getting the victim to install a Trojan? The latter could just literally monitor the user. I’m not saying your paper is technically wrong, just practically infeasible. Right now, you’ve chosen very specific websites. Have you explored if there is a correlation between specific scripts (react, jquery, etc) and whether websites with similar setups cannot be differentiated? I was also curious about content/non-homepage paths. Your conclusion seems to be that interrupts/etc are the primary indicators, so I suspect there’s a connection. Edit: In my experience, large websites and most web apps don’t use CDNJS/etc, but bundle their code - this would make injecting your script much harder without a supply chain attack. On second thought, given CORS I think this attack is actually impossible. How would your embedded script communicate your findings with your server? You would need to control the originating domain itself…
adrian_b 4y ago
The attackers do not read the CPU frequency, they estimate it based on the latency of the replies to their queries. The attack works only for certain combinations of CPUs and cryptographic algorithms that contain a mixture of instructions that cause a CPU to lower its clock frequency, with instructions that allow the CPU to raise its clock frequency. For such combinations, algorithms that are supposed to be executed in constant time are actually executed in a variable time, creating a side-channel. As a response to Hertzbleed, Intel has published a guide for those who write cryptographic libraries, about how to mitigate this vulnerability: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/frequency-throttling-side-channel-guidance.html https://www.intel.com/content/www/us/en/developer/articles/t... The main problem that creates this vulnerabilty is that the CPU vendors publish very little information about their turbo algorithms, so, unless you make your own measurements, it is very difficult for a software writer to predict at which clock frequency will be executed a certain segment of a program, and what should be done to avoid changes in the clock frequency.

advisedwang 4y ago

> Is this only a problem for platforms that can read the current CPU frequency? No, it just takes measuring the total wall-clock time of the relevant processing to exploit this.

kevingadd 4y ago

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.

karussell 4y ago
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"?
- adrian_b 4y ago
  With the performance governor, the clock frequency is continuously adjusted between the "base frequency" and the "maximum turbo frequency", e.g. between 3.7 GHz and 4.8 GHz, for my computer. With the powersave governor, the clock frequency is continuously adjusted between a frequency much lower than the "base frequency", and also the "maximum turbo frequency", e.g. between 2.2 GHz and 4.8 GHz, for my computer.
pyrolistical 4y ago
Haha so constant time algorithm isn’t constant time
- jaza 4y ago
  Time itself isn't constant, so arguably a constant time algorithm is an oxymoron! But that's a whole 'nother topic.

jackcook 4y ago

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/ https://jackcook.github.io/bigger-fish/

yunohn 4y ago
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.
- jackcook 4y ago
  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.
  - yunohn 4y ago
    I’m a little confused about your attack vector - how feasible would you reckon it is to place such a malicious script on the largest public websites in existence, versus just getting the victim to install a Trojan? The latter could just literally monitor the user. I’m not saying your paper is technically wrong, just practically infeasible. Right now, you’ve chosen very specific websites. Have you explored if there is a correlation between specific scripts (react, jquery, etc) and whether websites with similar setups cannot be differentiated? I was also curious about content/non-homepage paths. Your conclusion seems to be that interrupts/etc are the primary indicators, so I suspect there’s a connection. Edit: In my experience, large websites and most web apps don’t use CDNJS/etc, but bundle their code - this would make injecting your script much harder without a supply chain attack. On second thought, given CORS I think this attack is actually impossible. How would your embedded script communicate your findings with your server? You would need to control the originating domain itself…

adrian_b 4y ago

The attackers do not read the CPU frequency, they estimate it based on the latency of the replies to their queries. The attack works only for certain combinations of CPUs and cryptographic algorithms that contain a mixture of instructions that cause a CPU to lower its clock frequency, with instructions that allow the CPU to raise its clock frequency. For such combinations, algorithms that are supposed to be executed in constant time are actually executed in a variable time, creating a side-channel. As a response to Hertzbleed, Intel has published a guide for those who write cryptographic libraries, about how to mitigate this vulnerability: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/frequency-throttling-side-channel-guidance.html https://www.intel.com/content/www/us/en/developer/articles/t... The main problem that creates this vulnerabilty is that the CPU vendors publish very little information about their turbo algorithms, so, unless you make your own measurements, it is very difficult for a software writer to predict at which clock frequency will be executed a certain segment of a program, and what should be done to avoid changes in the clock frequency.