6 ms·

>What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Eh? Doesn't this require an attacker to actually be able to talk

by xoa 4y ago

>What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Eh? Doesn't this require an attacker to actually be able to talk to the targeted system? You mention classes of actor ("journalist, human rights activist, etc") that aren't online public service providers or at least perhaps shouldn't be. Private devices connecting out to the greater net are effectively universally behind firewalls and often (CG)NAT as well and not unilaterally addressable the other direction. For private services, access should be exclusively via VPN (direct WG or mesh like nebula or something) with PSK alongside public keys and perhaps something like port knocking in front as well. Same as with other hot class side channel attacks, the attacker does in fact need to be able to get the targeted system to run something somehow. So the most basic thing to do about it is simply not allow attackers to do that. The players for whom this is fundamentally impossible are general public online service providers, but that isn't the class most people or businesses fall into. If attackers are getting sensitive servers to respond to arbitrary code then they have already gotten access credentials of some kind.

BoppreH 4y ago
> 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.
- bobkazamakis 4y ago
  > 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.
  - _0w8t 4y ago
    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.
    - jabart 4y ago
      My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the returned time to 1 millisecond increments."
      - contravariant 4y ago
        Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?
        SOLAR_FIELDS 4y ago
        I know next to nothing about the internals of how the rounding code works, but couldn't randomly choosing to round up or down mitigate this somewhat?
        arpafaucon 4y ago
        If you round up and down with the same probability, it will get canceled on the long run. I suppose this does mitigate the risk a little, but risks breaking other things. For example, you don't have the simple logic sequence: a < b => round(a) < round(b) So I'd say "not worth it"
  - smaudet 4y ago
    I don't have a problem running JS but it is getting to the point where, if you can't prove you are JS worth running perhaps the browser should refuse to. Why have we gone from 'oh only run programs you trust not anything from the web' to 'oh just run every bit of bloatware out there any time you move around the web? 99% of JS should not exist, 0.9 % of it does anything useful and the other .1% is straight up malicious...
    - joveian 4y ago
      I do this with uBlock Origin. It is easy and I'd say less impactful than blocking third party domain (de-CNAMEd) CDNs by default (that I also do). Some sites just don't show anything without javascript, though, so it works best if you are often willing to just ignore those sites (not common but not all that uncommon either).
- xoa 4y ago
  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 to a desired web server, and you're imagining said server was hacked or otherwise compromised/untrustworthy and begins running Hertzbleed via JS, and that JS has the precision in practice for it to work. So vs other RCEs and such what is the path here? What short secrets (AFAICT these attacks aren't about pulling gigabytes of RAM but a few bits of key stuff) is it going after that, after having obtained them, represent a serious compromise by themselves or allow further escalation? Nothing done on the user device is going to affect the network hardware they're going through, and this attack is about reading not writing, so what is the attacker getting that will then let them break out of the web broswer/OS sandboxes and start pulling more the other direction? I can see that if other persistent access credentials were sitting unencrypted in memory that could be an issue if the attacker can use those to hop into other services the user has access to, but that's manageable via care with device usage, proper MFA etc right? Or I can see how true external IP address might be a dangerous short secret for someone trying to hide (vs merely secure) via VPN. But I think in those cases externalizing the VPN to the network level is a good idea anyway since being 100% sure of zero leaks in a modern OS/application stack is challenging, and then the user device doesn't have to know anything about the real IP at all. JS also already allows a huge amount of fingerprinting, so if someone is allowing JS to run and is deadly worried about privacy they must be thinking about mitigations there already. Again, not at all denying that incredibly tricky stuff can be done using little leaks like this to escalate in surprising ways. But for a dedicated web browsing device with only outgoing and session access to WAN, likely though a VPN but not necessarily on-device, what new threat scenario is this such that completely disabling dynamic frequency is the only response? Although I suppose for a dedicated web browsing device using tor browser or the like disabling that might not actually be a big deal anyway.
  - BoppreH 4y ago
    The exploit comes from a hacked server, a bad ad, social engineering, etc. As for the attack, imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data. This might sound very theoretical, but modern OS'es (and password managers) have lots of keys like that. There's a good chance one or more of them are reachable from Javascript. And that's just what popped in my mind in two minutes, I'm sure red teams will have better ideas. The scary part is that this is another attack in the same ugly class as Meltdown and Spectre, where the antidote is nearly as damaging as the poison.
- userbinator 4y ago
  Just like Spectre/Meltdown, it assumes you have an idea where to extract the secrets from, and more importantly what they secure. A string of random bytes is worth nothing to someone who doesn't know what they're the key to. ...and someone who is running JS is probably also running tons of other JS, adding even more noise to what already exists.

by xoa 4y ago

BoppreH 4y ago

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

bobkazamakis 4y ago
> 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.
- _0w8t 4y ago
  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.
  - jabart 4y ago
    My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the returned time to 1 millisecond increments."
    - contravariant 4y ago
      Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?
      - SOLAR_FIELDS 4y ago
        I know next to nothing about the internals of how the rounding code works, but couldn't randomly choosing to round up or down mitigate this somewhat?
        arpafaucon 4y ago
        If you round up and down with the same probability, it will get canceled on the long run. I suppose this does mitigate the risk a little, but risks breaking other things. For example, you don't have the simple logic sequence: a < b => round(a) < round(b) So I'd say "not worth it"
- smaudet 4y ago
  I don't have a problem running JS but it is getting to the point where, if you can't prove you are JS worth running perhaps the browser should refuse to. Why have we gone from 'oh only run programs you trust not anything from the web' to 'oh just run every bit of bloatware out there any time you move around the web? 99% of JS should not exist, 0.9 % of it does anything useful and the other .1% is straight up malicious...
  - joveian 4y ago
    I do this with uBlock Origin. It is easy and I'd say less impactful than blocking third party domain (de-CNAMEd) CDNs by default (that I also do). Some sites just don't show anything without javascript, though, so it works best if you are often willing to just ignore those sites (not common but not all that uncommon either).
xoa 4y ago
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 to a desired web server, and you're imagining said server was hacked or otherwise compromised/untrustworthy and begins running Hertzbleed via JS, and that JS has the precision in practice for it to work. So vs other RCEs and such what is the path here? What short secrets (AFAICT these attacks aren't about pulling gigabytes of RAM but a few bits of key stuff) is it going after that, after having obtained them, represent a serious compromise by themselves or allow further escalation? Nothing done on the user device is going to affect the network hardware they're going through, and this attack is about reading not writing, so what is the attacker getting that will then let them break out of the web broswer/OS sandboxes and start pulling more the other direction? I can see that if other persistent access credentials were sitting unencrypted in memory that could be an issue if the attacker can use those to hop into other services the user has access to, but that's manageable via care with device usage, proper MFA etc right? Or I can see how true external IP address might be a dangerous short secret for someone trying to hide (vs merely secure) via VPN. But I think in those cases externalizing the VPN to the network level is a good idea anyway since being 100% sure of zero leaks in a modern OS/application stack is challenging, and then the user device doesn't have to know anything about the real IP at all. JS also already allows a huge amount of fingerprinting, so if someone is allowing JS to run and is deadly worried about privacy they must be thinking about mitigations there already. Again, not at all denying that incredibly tricky stuff can be done using little leaks like this to escalate in surprising ways. But for a dedicated web browsing device with only outgoing and session access to WAN, likely though a VPN but not necessarily on-device, what new threat scenario is this such that completely disabling dynamic frequency is the only response? Although I suppose for a dedicated web browsing device using tor browser or the like disabling that might not actually be a big deal anyway.
- BoppreH 4y ago
  The exploit comes from a hacked server, a bad ad, social engineering, etc. As for the attack, imagine a browser that encrypts local storage with a system key. If I understand correctly, by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data. This might sound very theoretical, but modern OS'es (and password managers) have lots of keys like that. There's a good chance one or more of them are reachable from Javascript. And that's just what popped in my mind in two minutes, I'm sure red teams will have better ideas. The scary part is that this is another attack in the same ugly class as Meltdown and Spectre, where the antidote is nearly as damaging as the poison.
userbinator 4y ago
Just like Spectre/Meltdown, it assumes you have an idea where to extract the secrets from, and more importantly what they secure. A string of random bytes is worth nothing to someone who doesn't know what they're the key to. ...and someone who is running JS is probably also running tons of other JS, adding even more noise to what already exists.