It’s always best to start at the beginning, and in the case of Meltdown and Spectre, that could mean going back some 20 years as almost every processor manufactured during the past couple of decades seems to be impacted by these vulnerabilities. Both were actually discovered by a number of researchers, including those at the Google® Project Zero group, back in the summer of 2017. Working within the remit of responsible disclosure, the researchers combined resources with vendors, cloud providers, OS developers, and chip manufacturers to provide fixes, or relevant guidance where no fix was viable, within an agreed disclosure date of January 9th (Patch Tuesday). Unfortunately, the news leaked a week ahead of schedule and that’s when all hell broke loose. Some patches were brought forward, others remained in the shadows, and a speculation epidemic hit the national news headlines.
So I’ve already mentioned that Meltdown and Spectre are a trio, rather than a pair, of critical vulnerabilities, so let’s delve a little deeper. Meltdown refers to CVE-2017-5754 (sometimes referred to as ‘Variant 3’) and causes the mechanism that prevents unprivileged processes from reading kernel/physical memory to melt away. It enables an attacker to execute instructions ‘out of order’ before an exception is raised, so skipping the technicalities involved means that an attacker could potentially access the memory of different virtual machines hosted on the same cloud servers.
Spectre, meanwhile, refers to the Variant 1 CVE-2017-5753 and Variant 2 CVE-2017-5715 vulnerabilities. The first variant is a bounds check bypass that could be exploited via a browser client to run arbitrary code and read data that should be out of reach. The second is a branch target injection vulnerability, which could also read data via a browser-based attack and potentially enable the reading of host memory using a virtualized guest account.
All three have the potential to be game-changers, all three have the potential to extract passwords and encryption keys, all three are isolation compromise attacks. In brief, the difference is that Meltdown targets isolation of OS from an executed application (enabling untrusted communication via the kernel), whereas for Spectre it’s the isolation between executed applications themselves (enabling applications without vulnerabilities to be exploited).
Remember that Amazon Web Services™ (AWS®), Google Cloud Platform, and Microsoft® Azure® had all been working on fixes for six months prior to these vulnerabilities being disclosed. None can claim to be 100% secure against Meltdown and Spectre, but the vast majority of the hardware deployed by each had mitigation against them in place before the news broke.
Also, as far as anyone can tell, there have been no real-world attacks exploiting either Meltdown or Spectre vulnerabilities. At least, none that have emerged from the shadows. It certainly doesn’t mean you can relax as of yet. Security researchers have already found in excess of 130 malware samples that all appear to be proof-of-concept ‘test’ code looking to exploit the various vulnerabilities. Don’t expect this criminal-research phase to last forever; at some point targeted attacks will commence and will hit those organizations that haven’t already patched browser clients and operating systems.
Gartner® has identified a seven-step plan for mitigating the Meltdown and Spectre risk, which is detailed in the ‘Security Leaders Need to Do Seven Things to Deal With Spectre/Meltdown’ report.
The seven suggested steps are:
These map quite well, as bullet points, to the MSP sector. Not least as shared, cloud-based, systems are particularly at risk from attackers once they get exploits out into the wild. Then there’s the concern over implementing OS patches, which, while fixing the vulnerabilities, bring with them a performance hit. Thankfully, server performance impacts are now proving to be less problematic than at first experienced as the fixes have evolved. Browser client patching is certainly a no-brainer, removing the easiest attack vector for potential exploiters.
Testing, monitoring, and managing patch deployment will be the key to ongoing mitigation of the Meltdown and Spectre risk, which shouldn’t be problematic as all three are part and parcel of being a good MSP. Lead by example to ensure client confidence in your services, keep on top of both risk and mitigation as they evolve.
Davey has been writing about IT security for more than two decades, and is a three-time winner of the BT Information Security Journalist of the Year title. An ex-hacker turned security consultant and journalist, Davey was given the prestigious 'Enigma' award for his 'lifetime contribution' to information security journalism in 2011. You can follow Davey on Twitter® at @happygeek.
© 2018 SolarWinds MSP UK Ltd. All rights reserved.
This document is provided for informational purposes only and should not be relied upon as legal advice. SolarWinds makes no warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information contained herein.