Hertzbleed Attack. Should you worry?

Hertzbleed Attack. Should you worry?

How time flies! It's already 10 years since Heartbleed, and there have been many major zero-days and other vulnerability disclosures before and after that. Now the Hertzbleed Attack is the new Heartbleed, or rather the new Spectre. Should you worry?

We in the computer security field are chronically worried. The software and hardware we deal with is incredibly complex. A great deal of work is being done to systematically reduce risk, but it is impossible to know if we've fixed every bug and patched every hole. Enter Hertzbleed.

Computers and ordinary clocks have a different view of time. The clock on your office wall ticks every second, like clockwork, because that's what it is. We call this wall time. Every second is as long as the previous one, barring minor inaccuracies, very minor relativistic effects, and your feeling that time always flows slower on Mondays. Computer clocks "tick" every time the CPU processes a new set of instructions, which can be several billion times per second. They are very regular, yet also variable. They can run faster or slower depending on the workload, sprinting when there's work to do and slowing down to save power when they're idling. This is dynamic frequency scaling, and it means that computer time flows at variable rates from the software's point of view. Modern CPUs scale rapidly up and down all the time.

A timing attack exploits the fact that computer instructions take different amounts of time depending on what data they work with. Such attacks can for instance reveal passwords. We defend against them by writing constant time code. We ensure that security critical code takes the same time to run, regardless of what it's doing. We can do this by making the program sleep a certain amount of time after it's finished, so that the work time and sleep time adds up to a constant number. That means the elapsed wall time doesn't change no matter what data you send, and timing attacks fail.

A side-channel attack doesn't exploit bugs, but the fundamental way things work, when they are working as they should. For instance, you don't need to unlock a laptop to tell if it's idling or working hard, you can simply listen to the fan or touch it to check for heat. The heat is a fundamental side-effect of a computer doing what it's supposed to do.

The researchers that discovered Hertzbleed found that they could detect how hard a computer is working by detecting how the CPU frequency scales up and down. This can be done by sending carefully crafted instructions that are known to take a certain amount of computer time, and then measuring how much wall time they take. If the wall time is short, they know the CPU frequency is high, meaning it's working hard. The frequency scaling can break some kinds of constant time code, making it variable. And so a side-channel attack can be turned into a timing attack. They managed to use this technique to extract encrypted secret keys.

How bad is it? Most CPUs are affected: Servers, laptops, cell phones. The issue can't be "fixed" in hardware or microcode because it's fundamental to how CPUs work. It must be fixed in software. Exploitation in the wild may be possible, but is unlikely in a busy multitasking server context. All the various unpredictable processes running at the same time adds "noise" to the timing "signal" the attacker is listening for, and when the signal-to-noise ratio is too low, the attack fails. The internet itself also adds random timing noise, which increases with the distance between attacker and target.

Will Ibexa release a fix? No. Ibexa DXP is high level software that sits on top of Symfony, PHP, libraries and operating systems. Hertzbleed is impossible to deal with on our level of the software stack, it must be checked for and if necessary fixed lower down in security libraries like SSL, and operating systems.

What should you do? Keep your software stack up to date with security fixes as soon as possible after they are released, all the way down to system libraries and the OS. Redeploy your cloud stack when needed to apply fixes there. And sleep well!

Insights and News