Why We Should Care About CPU Vulnerabilities

From a security perspective, 2018 has been The Year of CPU Vulnerabilities. On January 3, 2018, the public learned of the Spectre and Meltdown CPU vulnerabilities, followed by a flurry of activity to create workarounds to address these issues. Announcements in June 2018 of TLBleed followed Spectre and Meltdown, and in August 2018 of the Foreshadow CPU vulnerability. While TLBleed exploits a weakness in the Intel hyper threading model to expose encryption keys, Spectre, Meltdown, and Foreshadow vulnerabilities exploit weaknesses in the security of the speculative execution mechanisms in Intel and (in some cases) other processors. These vulnerabilities allow malicious programs to access sensitive data in memory or CPU level 1 cache. Workarounds to these vulnerabilities partially or completely disable speculative execution, with significant negative impacts on performance. Intel’s stated fix is for users to switch to its new family of processors (starting with Cascade Lake) that address these issues.

From a user perspective, these security vulnerabilities can easily fall into the “cognitive dissonance” (also known as the “bury your head in the sand”) trap. For most users, especially desktop/laptop users, performing a “forklift upgrade” or utilizing performance-crippling workarounds is a big negative that is hard to justify against the perception that they are unlikely to be attacked (“what do I have that is of value?”). For large data centers, implementing additional security measures to avoid Spectre/Meltdown/Foreshadow-laced malware might be more attractive than taking a huge performance hit and deploying more servers to take up the slack.  However, the real danger of CPU vulnerabilities is exactly that they make it easy to defeat all security measures running on servers and endpoints, potentially opening a door for the massive infiltration of additional malware. This is why everyone should care about CPU vulnerabilities, as unattractive as the workarounds or solutions might be.