5 ms·
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 V
by 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 agoThe 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.
- lossolo 4y ago> 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. Don't you need precise clocks for this in JS? The ones that were disabled in browsers after Meltdown/Spectre.
- thepangolino 4y ago>by storing different patterns of bits, Hertzbleed might be able to extract the system key from the timings to save data. Isn't that practically impossible given the amount of random software running on a regular computer nowadays? This is not based on hdd write speeds but processor timings which are affected by every single cat video you are watching.
- mgiampapa 4y agoOn most shared infrastructure would be even harder to exploit. In an ideal world you are sharing the infrastructure to maximize CPU and other resource utilization. When running workloads on VMWare for example, the best practice is to disable deep C states and not allow the CPU to dynamically scale down. This prevents all kinds of clock drift issues in guest VMs that expect a CPU cycle to be relatively constant.
- angry_octet 4y agoThis is not about power saving, it is dynamically, on the granularity of individual instructions, balancing the thermal dissipation available across cores. When some cores are relatively idle (e.g. waiting on cache fill) it uses the available amps to run other cores at "turbo boost" frequencies. For some single threaded code we force other cores to idle so that one thread can get maximum cache and maximum frequency. A similar approach could be used to minimise the power analysis signal.
- neurostimulant 4y agoMany password managers are using end-to-end encryption and have browser extensions written in js. It would be bad if hertzbleed can be used to extract keys used by those password manager extensions.
- progval 4y agountrustworthy server that runs malicious JS: potentially half the links one clicks on HN or Reddit short secrets which aren't mitigated by MFA: session cookies, TLS client certificates, secret keys of e2ee IM apps (eg. Element), Zerobin URLs, ... Maybe even TLS session keys?