Can this attack be used to extract Widevine decryption key?
Hertzbleed Attack
151–160 of 406 posts
Re: Hertzbleed Attack
#152This paper relies on Turbo P-states, where they measure the oscillation when that is active; it is not measuring general SpeedStep (OS software controlled) as some seem to have taken away from it. Turbo state is the HWP (hardware P-state controlled) layer above SpeedStep; turning off Turbo in the BIOS still fully allows OS controlled SpeedStep P-states to function, it just disables the hardware level bursting P-states above that max listed CPU level for short periods of time. As others have noted, Turbo state can really kill a laptop battery and/or drive up the thermals pretty quick, a lot of folks disable it anyways if they've tinkered around before.
The abstract writes it as "When frequency boost is disabled, the frequency stays fixed at the base frequency during workload execution, preventing leakage via Hertzbleed. This is not a recommended mitigation strategy as it will very significantly impact performance." This is a confusing grammatical way to state it, as SpeedStep will still work at the OS layer, you'll scale min to max "as usual" and just lose temporary hardware boost max+ capability when under stress (full load at P0 state) - not really "fixed" as it were in layperson's terms. That would be more akin to saying SpeedStep had to be disabled, IMHO.
https://www.kernel.org/doc/html/v4.19/admin-guide/pm/intel_p...
Re: Hertzbleed Attack
#153A lot of people here commenting about shared hosting in clouds, but I don't see any actual text that shared environments are more vulnerable. It sounds like a black box timing attack that could target my laptop, my phone, my server, anything that does cpu frequency scaling and is performing a computation that is susceptible to this attack. Is that accurate?
Your devices probably aren't responding to unsolicited network requests from the internet.
But they do run arbitrary javascript code in my browser.
Re: Hertzbleed Attack
#154Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto. The need for constant time should have first class support on the language/compiler…
Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.)
Downthread: https://news.ycombinator.com/item?id=31745105
Re: Hertzbleed Attack
#155Earlier quoted context omitted.
> 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…
> 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.
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.
Re: Hertzbleed Attack
#156Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto. The need for constant time should have first class support on the language/compiler…
Simplest solution here is to implement the algorithm in hardware, with a new instruction that has all the security attributes. (Including resistance to power differential and timing differential attacks.) Downthread: https://news.ycombinator.com/item?id=31745105
But this is inflexible.
Re: Hertzbleed Attack
#157Earlier quoted context omitted.
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?
It wouldn't, not by itself. The attack would take more measurements to create a profile, however. Extending the time required to mount an attack is probably not sufficient to thwart an attack. It could be for some workloads, but not for all.
Re: Hertzbleed Attack
#158Interesting that the mitigation is to turn off Turbo/Precision Boost. Four or five years ago there was an an article submitted here (I wish I could find it) about a developer who keeps a machine with Turbo Boost disabled specifically because it seemed to interfere with their performance testing. By keeping it disabled they were able to eliminate a number of factors that prevented them from getting consistent results.…
These "optimizations" might not matter in the end though if the production environment runs with Turbo Boost enabled. Unless they are verified on another machine of course.
Re: Hertzbleed Attack
#159Brilliant 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…
> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. A server running a multithreaded load is probably disabling turbo boost anyway because of the thermal load on the package already. Instead, you should disable speedstep and set your systems to maximum performance. However, this will increase the heat and your power bill considerably.
A spike performance up, random delay in down might be sufficient mitigation on a multi-tenant platform.
Re: Hertzbleed Attack
#160Given that cloud providers oversubscribe their rack power supplies for $ reasons, I'm waiting for the cloud-level equivalent of this DVFS attack, where you throttle a competitor cloud instances by bursting on collocated instances of yours :)