A Few Thoughts on the Spectre & Meltdown Vulnerabilities

2018 has started off with a bang in the security arena. Shortly after ringing in the new year, security researchers disclosed the existence of the “Meltdown” and “Spectre” attacks on modern CPUs.  These vulnerabilities represent a very rare event in this industry: the discovery of an entire new class of attack.

When we think of a computer, most people have an innate understanding, and expectation, that every program exists in its own space.  Your Chrome web browser should not be able read memory being used by Microsoft Excel.  In a nutshell, these new vulnerabilities break that barrier.

Traditionally, vulnerabilities are usually the result of coding errors in software.  Software developers are human and sometimes make errors or omissions in their code that is then later exploited as a vulnerability.  “Meltdown” and “Spectre” are different.  They do exist in software but rather exploit a feature in the very silicon of the CPU itself.  The feature in question is called “Speculative Execution” and without getting into the overly technical, it’s a mechanism where the CPU tries to predict what it will next be asked to do, speeding up all the software the computer runs.  It is this feature that lies at the heart of the issue.

By all accounts, the “speculative execution” capability of the CPU was thoroughly and thoughtfully designed.  The ability to co-opt this performance-enhancing capability for evil was never even considered, and for many years never was.  As a scientist, this is the nature of discovery.  Smoking was once thought to be fine, if not healthy.  Then one day it wasn’t.  We don’t fault the first cultivators of tobacco hundreds of years ago for the health effects we see today.  Likewise, I do not believe Intel and the other manufacturers deserve blame for this issue.

As consumers and vendors, we have to be very careful and measured in our response.  For the vulnerabilities we are all used to, the vendor simply issues a software patch and that is that.  This is different.  Since the feature that is exploitable is implemented in silico, we can’t just go in and change the hardware.  We have to use software to work around it.  This would be analogous to trying to fix a problem with your car’s engine by changing the transmission.  The initial software fixes that have been created to address this may cause significant performance problems, especially on older systems and busy servers.  For the only time I can ever remember, Microsoft is actually warning customers to consider not applying their security patch if the system in question does not run untrusted code.

This is the crux of the mitigation.  In order to exploit “Meltdown” and “Spectre” you have to be able to run a purpose-built program on the CPU.  In multi-user and virtualized  environments, especially public clouds, we absolutely want to patch this at all cost because we can’t control what software the system is going to run.  Indeed, all of the major public clouds have already done so.  However, if you have a carefully managed system where general user is not allowed and software is carefully vetted and approved, such as a database server, one may want to consider the risk versus benefit of applying the current patches.  Most appliance manufacturers are not currently applying patches to closed systems like storage arrays and network switches since there is no avenue for a malicious party to install and run a program to exploit these vulnerabilities.  Security is not a “one size fits all” business, and a clear data-driven and evidence-based approach is needed when deciding whether or not to patch.  While early work-around patches are indeed available, they should not be blindly applied.

The entire industry is going to wrestle with these issues for years, if not decades, to come.  The good news is that we will learn and adapt, and in the end computing will be that much more secure.  Until the next new thing.