Should you Patch Spectre and Meltdown?

Many ops teams reflexively patch all important vulnerabilities. But is it always necessary for Meltdown and Spectre? Manish shares his thoughts on when you need to patch.

Although this isn’t a security blog, security is certainly a recurring theme for application developers and operators alike.  The recent Spectre and Meltdown vulnerabilities are especially difficult because, for Spectre, there are only mitigations and no complete fixes.  For Meltdown there is a software fix but it can incur significant performance penalties –  over 20% in some cases.  Like I said in my meltdown video, I can imagine scenarios where the performance penalties are much worse than this.  The only saving grace is that more modern Intel processors (Haswell and later, if memory serves) show less of a performance penalty than older processors due to certain memory management features.

In the video below, I share some of my thoughts.  Below is a quick summary.

DISCLAIMER: This video and discussion below is not a complete analysis. You must consider individual circumstances with a good understanding of the vulnerabilities and performance impacts to make the best decision on a case-by-case basis.  You have been warned.  If you feel I’ve missed any important considerations, please leave a comment below.

To Patch or not to Patch?

For Meltdown, there are 4 cases to consider:

1. Your application shows little or no impact from the meltdown fix – This case is easy. Just apply the patch and move on.  Even if the system does not run untrusted code, attackers can always use one vulnerability to gain limited access and then others to escalate their access.  You do have a good, representative benchmark suite just for quality purposes, right?
2. The system regularly runs untrusted code and has privileged data – Let’s face it, all systems have data you probably don’t want attackers to see.  If the system regularly runs untrusted code, you should probably patch and figure out how to deal with the performance penalty.  As far as I know, there is no way to isolate code from the Meltdown vulnerability if it is running on affected hardware.
3. You rely on a hypervisor or operating system kernel for breach containment – If your security posture relies on containing breaches using the operating system (containers, zones, LXD, etc.) or virtual machines (VMs) then you need to patch.  In other words, if you expect that a breach of one VM will not spill over easily into a breach of another running on the same system, you must patch because Meltdown would allow an attacker to steal data from an adjacent VM.
4. You run your code on a third party service – If you can run code on that third party service (AWS, Google Cloud, etc.) then so can attackers.  You should make sure your vendor has patched the vulnerabilities or provides dedicated hardware for each customer.  Continuous Integration and Continuous Deployment SaaS solutions like are particularly important, especially if the deployment pipeline has authorization to deploy to production.