A summary of the most important points regarding Meltdown and Spectre to the average person
This is legitimately a Big Deal (TM). This is a problem with performance features of CPUs that makes it possible to bypass protections between processes in userspace and processes in kernel (privileged) space. In other words, Meltdown and Spectre break down the protective barriers in memory (RAM). Since it’s a CPU issue, Windows, MacOS, iOS, Android and ChromeOS are affected (but to varying degrees). As it’s not feasible to simply issue wholesale replacements of physical CPUs (and there’s no ‘fixed’ versions to replace them with), we’re going to be stuck with imperfect software patches.
What are the issues?
First off, we’re not going to get too technical on how these work. There are better posts for that with the best probably being the main website set up for these issues and the accompanying research papers.
There are two core issues and they have names: Spectre and Meltdown. There are three CVEs assigned to these — one to Meltdown (CVE-2017–5754) and two to Spectre (CVE-2017–5715 & CVE-2017–5753). Spectre has two CVEs, because there’s two techniques involved. Both issues aren’t bugs, per se — they’re performance features that have been implemented on CPUs for some time. The problem is, abuse cases for these features weren’t properly tested or mapped and chip manufacturers either didn’t realize there were security trade-offs or decided to quietly accept the risk and go ahead with design and production.
The short version? We’ve traded performance for security without knowing it. Well, at least until now.
There are, as of yet, no CVSS scores for these issues, but the confidentiality compromise should be considered complete. These issues are both information disclosure-related. There is no way to inject code or escalate privileges with these vulnerabilities unless some of the information leaked includes credentials or other auth secrets that can be used to escalate privileges. This is an indirect case though. The vulnerabilities only allow reading privileged memory.
Going a bit deeper, using different side-channel techniques, both Spectre and Meltdown allow unprivileged user processes to access privileged kernel memory. This is particularly an issue in multi-tenant cloud and server scenarios where customers have the ability to load and run arbitrary code and could possibly access sensitive data belonging to other customers. From what we’ve seen, virtualized multi-tenant systems aren’t vulnerable. That means services like AWS’s EC2 won’t be affected, but multi-tenant web hosting (e.g. GoDaddy, Dreamhosting, etc) and container services (e.g. Docker or Kubernetes-based) that aren’t isolated to one physical host per customer are.
The big problem here is that the core issue is with how modern CPUs function. These issues represent a new class of vulnerability we haven’t seen before — hardware performance optimizations that have an adverse impact on security. While some manufacturers may update microcode to address the security issues here, Intel is currently holding stance that these are not bugs and therefore, there’s nothing for them to fix. The result is that we’re going to see a mad flurry of software patches to address these issues. Mitigating these issues in software is far from perfect and the researchers behind Spectre and Meltdown emphasize that mitigations like the KAISER mitigation should be considered temporary solutions.
The other shoe to drop here is that mitigating security issues that result from CPU performance improvements is going to result in performance degradation. We currently don’t have solid numbers on how much, but the hair-on-fire folks on Twitter are currently running around screaming about 30% performance hits. That sounds a bit extreme to us, so we’ll continue looking for more solid numbers on performance impacts. Conversely, the researchers behind KAISER claim only a 0.28% performance impact. Maybe someone got mixed up and moved the decimal two places to the right?
Meltdown is currently believed to only impact Intel chips, whereas Spectre’s impact affects AMD and ARM chips as well. This broadens the collective impact to cover most servers, PCs, desktops, laptops, tablets, phones and other devices containing these general-purpose CPUs. Some software patches address Spectre by degrading the precision of high-resolution timers. In other words, software patches can make it more difficult to succeed with the Spectre technique.
Note, however, that researchers say that there’s still a lot of work to do in this area of research. This is the introduction to Microarchitectural vulnerabilities, so we might see further research that’s able to exploit Meltdown on non-Intel CPUs, for example.
What are the attack vectors and prerequisites?
How reliable and exploitable is it?
Meltdown is said to be fairly easy to exploit, but is also easier to mitigate. The KAISER patch had already been formulated as a defense for different attacks against ASLR and coincidentally addressed Meltdown as well. It does nothing to mitigate Spectre, however, though the silver lining is that Spectre is also more difficult to exploit usefully.
Proofs of concept exist and are generally available. Searching Github for the CVE numbers or names of the vulnerabilities will get you some sample code.
What’s the fix?
For Meltdown, the fix is software patches — a multitude of which have already been released. Many more are currently in development, including some coming from Intel directly. Like KRACK and Blueborne, this is an issue that affects many devices and platforms. The official site for this issue has links to responses from most of the big vendors at the bottom of the main page. It’s not just operating systems issuing patches either: the major browsers are issuing updates, Intel is working on firmware updates and there’s likely a lot of embedded and proprietary systems that will issue updates.
Microsoft has a PowerShell module that will help check to see if mitigations are in place, as well as additional guidance for administrators.
PS > Install-Module SpeculationControl
PS > Get-SpeculationControlSettings
What is the fix going to break?
On all systems receiving patches for Meltdown, there will be an associated performance impact. You can’t really mitigate a security issue related to performance optimizations without undermining those optimizations. Phoronix, a website dedicated to Linux-related articles on hardware, performance and benchmarking has several pieces on this impact, with results that vary by use case. For example, gaming performance doesn’t seem to be impacted, but server workloads suffered considerably in many cases.
On Windows, we’re seeing a good bit of software with kernel-level hooks breaking — specifically, anti-virus software. Particularly, AV software with Windows kernel hooks (which is most of them) are affected. This includes next-gen AV products, EDR products and many other endpoint security-related products. Microsoft found in early testing that the patch resulted in many AV products causing blue screens.
To mitigate this, anti-virus vendors must set a specific registry key for the Meltdown/Spectre patch to get applied. This allows AV vendors put a hold on the update until they can ensure their product is updated and ready to work with the patch. Kevin Beaumont was kind enough to put together a spreadsheet showing the status of various AV vendors on getting their products updated. This spreadsheet is getting updated as AV vendors release software updates that are compatible with Microsoft’s patch.
And that’s not all!
Additionally, even after the Microsoft patch is applied to server operating systems, the default behavior is not to enable the mitigations. You’ll have to edit the registry to enable them. Perhaps fear of significant performance impacts led Microsoft to make this choice? Again, like we’ve seen with the Linux testing, testing so far suggests that Windows desktop users shouldn’t notice anything. We’ve yet to find any Windows server benchmark tests before and after applying the patch.
Are there alternative mitigations?
Preventative measures that isolate, segregate or virtualize memory may mitigate these issues. You should test to verify this case though – don’t assume it does. Examples include Bromium and QubesOS, both of which can run processes in different virtualized memory spaces.
Can it be detected?
Update 1/6/2018: Capsule8 has announced the ability to detect the use of Meltdown exploits while hinting that further detection capabilities will include Spectre as well. Detection code is available now and is said to be reasonably free of false positives and false negatives. It also reportedly has a negligible performance impact. With increasing reports of significant performance hits related to the patch that mitigates Meltdown and Spectre on Linux, this begs the question: if we can automatically detect and stop Meltdown and Spectre attacks, do we need the patch? Isn’t it doing more harm than good at this point?
We’re keeping our eyes peeled and fingers crossed for similar detection capabilities for Windows.
Theoretically, yes. We need to research these issues more to determine whether or not it is practical to detect these attacks, however. We’ve not seen any detection tools or techniques so far.
This research could significantly impact chip design in the future, putting more focus on improving security. The end result could actually be better performance in the long term, while enjoying more resilient architecture at the hardware level. Along with the researchers, we don’t understand the microchip industry well enough to understand what the timeline would look like for permanent improvements and fixes related to these issues.
What we do have to go off of is a rich history of CPU bugs, especially with Intel. If you’ve been around long enough, you may recall that the Intel Pentium had a lot of issues when it first came out. The Pentium FDIV bug resulted in faulty floating point calculations and was serious enough that Intel physically recalled chips, taking a half-billion dollar hit at the time (December 1994). A few years later, the Pentium F00F bug was discovered, which could cause the processor to ‘hang’ until the system was rebooted. In contrast to the FDIV bug, Intel decided not to issue a recall, instead, letting operating system vendors address the issue in software by detecting the bug and intercepting this ‘killer’ instruction.
In the case of Meltdown and Spectre, Intel is claiming nothing is wrong. The issued press release avoids even discussing the issue at hand, instead deftly using language to step around the discovered issues. Simultaneously, the press release mentions that “Intel has begun providing software and firmware updates to mitigate these exploits”.
Guest post by Adrian Sanabria of Savage Security.