listen to this article:
Since hitting the news early January, the havoc caused by Meltdown and Spectre refuses to abate. These software side-channel attack vulnerabilities affect current and past processors, from 1995 and on.
Problems with Patches
Over the past few weeks, Intel has worked diligently to release software/firmware patches for the vulnerabilities (with the understanding that Spectre cannot be fully mitigated), in coordination with OEMs, cloud service providers, system manufacturers, and software vendors. However, it turns out that the initial patches released caused issues like spontaneous rebooting, resulting in an official recommendation from Intel to wait for a new version of the patches. Exact timing for the new patches has not been announced as of yet.
So, what makes patching these vulnerabilities so hard? As discussed in our previous post about the issue, both Meltdown and Spectre utilize speculative execution, a CPU performance enhancement technique where the CPU processes instructions and reads memory ahead of time, by guessing the likely future instructions to be processed (if the guess is wrong, the processor rewinds the state back). While enhancing performance, it turns out that this technique effectively allows malicious processes to read each other’s memory. The root issue stems from the fact that different programs share the same resources (e.g. CPU, cache, memory) and thus a complete fix would require redesign and replacement of the CPU – which is very costly and not realistic for existing CPUs given the immense magnitude of systems and devices affected.
Fixing Hardware Vulnerabilities
As hardware replacement is impractical, software patches were released: however, they cannot fully prevent Spectre, and hit performance by up to 30%, depending on the specific workload. Last week, as mentioned, these patches were found to be problematic and now new versions are expected. As we have seen previously with ROCA, while hardware is typically considered safer than software, it has serious agility and longevity issues. Fixing hardware vulnerabilities is very tricky, especially when the problem is deep down in the stack, in the CPU itself. In such cases, it is not only that a complete fix may require equipment replacement, but the propagation of software patches through the supply chain is also slow, rendering systems exposed for very long periods of time.
During the last decade or so, many software vulnerabilities have been discovered, and the industry is now accustomed to consuming critical updates at the speed of software. This is not at all the case with hardware vulnerabilities. With the proliferation of vulnerabilities and the frequency in which they are discovered and exploited by malicious adversaries, anyone who uses, designs or develops secure systems should ask themselves some difficult questions:
- How fast can we respond when things go wrong? (and yes, they will).
- For how long will we be exposed?
- What will be needed in order to recover? is it a software update, firmware update or a full equipment replacement?