The dust is settling around Meltdown and Spectre attacks, and most vendors have released statements or patches resolving the vulnerabilities. Here’s everything you need to know:
The Bottom Line
A pair of exploits affecting nearly every modern processing chip could give attackers the ability to steal a wide-variety of highly sensitive information. The underlying vulnerabilities affected nearly every Intel chipset manufactured since 1995 as well as various ARM, AMD, Qualcomm, and other proprietary chips. At present, these attacks, named Meltdown and Spectre, are codified under three CVEs: CVE-2017-5753, CVE-2017-5715, and CVE-2017-5754.
Late in the afternoon on Tuesday January 2, 2017, details started to emerge surrounding a serious, decades-old security vulnerability affecting the vast majority of Intel processors. Though little was known in the way of specifics at the time, the bug was thought to impact nearly every Windows, MacOS, and Linux machine, as well as certain Android and other mobile devices and some cloud service platforms. On affected machines, an attacker could compromise an application or develop a malicious program that would be capable of stealing highly sensitive information accessible to the kernel, information potentially including passwords, sensitive documents, and more. Problematically, while rumor had it that fixes were either available or under development (depending on the operating system in question), the patches mitigating the vulnerability could cause a performance hit of between five and 30 percent on fixed machines. As it turns out, the finer details of the vulnerability had been protected by an embargo that lifted on the evening of Wednesday January 3. While it’s not clear when that embargo first went into effect, Google says it informed Intel, AMD, and ARM of the problems on June 1, 2017.
Meltdown and Spectre
Technically exploits rather than vulnerabilities, Meltdown compromises the isolation between user-programs and operating systems while Spectre compromises the isolation between applications. The former is easier to exploit and easier to fix while the latter is both more difficult to exploit and more difficult to fix.
Oddly, both attacks and the vulnerabilities that enable them were disclosed to Intel by no less than four distinct groups with no relation to one another, in a phenomenon known as a bug collision.
We’ll start with Meltdown:
Meltdown targets the memory data security of machines running on the Intel x86 architecture, rendering it possible to read arbitrary kernel memory by abusing an optimization technique called “speculative execution.” In essence, Meltdown makes it possible for unprivileged user-level applications to access highly privileged kernel memory. In the words of the researchers who discovered the vulnerability, “Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer.” As Cyberus Technology, one of the firms that reported the exploit to Intel, rightfully points out, “Reading kernel memory implies reading the memory of the whole system on most 64 bit operating systems, i.e. also memory from address spaces of other processes.”
Practically speaking, Meltdown circumvents the isolation barrier between the kernel-space and the user-space within the Intel x86 architecture. It does this by leveraging side-channel information leaked by the cache during speculative execution. Ultimately, the attack is enabled by the interplay of virtual memory, memory that is cached in order to expedite program execution, and, as we’ve already mentioned, speculative execution. The attack bypasses a virtual memory protection that is supposed to prevent user-applications from mapping out memory locations in the kernel. The memory cache is designed to overcome the reality that accessing memory is slow compared to CPU speeds, but it also inadvertently reveals “which spots of the memory are warm (cached) and which are cold (not cached), which is a crucial part of the attack.”
Put briefly, speculative execution basically alleviates processing units of the need to fetch instructions from memory—and to later maintain the integrity of long strings of instructions—every time they’d like to execute a process or program. Speculative execution allows for a sort of intelligent guessing of instructional flow paths required to access the data needed to execute processes and programs. This technique also allows processors to access cached data to rapidly determine if a certain program is allowed to access certain data. When a path is guessed wrong or a program is deemed to not be allowed to access certain data, the speculatively executed instructions are discarded. Problematically, these are discarded in such a way that there is a measurable impact on the cached memory subsystem.
If Meltdown is about user-level applications accessing privileged system data, then Spectre is about rogue applications or attackers tricking legitimate applications into allowing access to sensitive application data. The Spectre attack relates almost entirely to the speculative execution technique, and it allows an attacker-controlled or rogue application to force side-channel leaks of confidential information during the speculative execution process by compelling the victim machine to perform speculative operations that would not occur during normal program execution. In other words, Spectre abuses speculative execution to compel processes and programs into dumping secret information into the processor cache. As alluded to above, modern CPUs use speculative and branch execution to maximize system performance. Per the researchers, “speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks.”
Put succinctly, speculative execution violates the fundamental security assumption “that the CPU will faithfully execute software, including its safety checks” in ways that “allow adversaries to violate the secrecy (but not integrity) of memory and register contents.” In turn, the speculative execution technique undermines a wide variety of software isolation techniques.
Both exploits enable the theft of potentially sensitive information. As Wired’s Andy Greenberg aptly put it, the Meltdown attack means that “any hacker who could run code on a target computer could break the isolation around that low-privilege program to access secrets buried in the computer’s kernel like private files, passwords, or cryptographic keys.” By extension, in virtualized environments, a malicious virtual machine (VM) could conceivably pilfer information from other VMs that reside on the same physical server. Alternatively, Greenberg explained that an attacker could leverage Spectre to force a program—like a Web browser—to leaks sensitive data—like browsing history or passwords.
Spectre-related CVEs are CVE-2017-5753 and CVE-2017-5715. The Meltdown CVE is CVE-2017-5754.
Mitigations by Vendor
Microsoft has released security updates for Windows 7, 8.1, 10, Server 2008 R2, Server 2012, Server 2012 R2, and Server 2016 to mitigate this issue. Microsoft has acknowledged that there are some antivirus providers that do not comply with the required changes to the Windows Kernel resulting in blue-screen-of-death (BSOD) errors. Microsoft has initiated a “smart” patching process that will attempt to identify if a non-compliant antivirus solution is installed and will refrain from installing the patch. Microsoft has indicated that they are working with antivirus vendors to ensure they become compliant—a process that involves the antivirus providers setting a specific registry key that can be found here. No information appears to be publicly available identifying which antivirus vendors are not compliant at the present time. That said, Microsoft has run into similar BSOD issues on some machines running AMD chips. Beyond this, Microsoft has issued various guidance for SQL server, Windows Server, and Windows endpoints.
Reports based on unnamed Apple employees stated that Apple issued a partial mitigation in the release of 10.13.2 patch to High Sierra. Patches to both Sierra and El Capitan were also issued at approximately the same time, however there is no information either way on those patches. Apple’s 10.13.2 security bulletin contained kernel fixes disclosed by Jann Horn, one of the researchers credited with discovering the Meltdown and Spectre attacks, although there is some disparity among the credited CVEs.
Apple updated its early December patch advisory on January 5, adding information about a kernel fix that resolved Meltdown (CVE-2017-5754). Beyond that, on January 8 Apple released security updates attempting to mitigate the effects of Spectre (CVE-2017-5753 and CVE-2017-5715) in iOS, Safari, and macOS High Sierra.
Red Hat has released some patches to mitigate this vulnerability within Red Hat 7, as well as advanced support editions 6.7, 6.6, and 6.4. Patches for the remaining supported version of Red Hat are pending and Red Hat recommends updating as soon as the patches become available.
One exception to this, however, is Red Hat Enterprise Linux 7.2 and greater. Those versions will require a firmware update to patch against this vulnerability. Per Red Hat: “Subscribers are advised to contact their hardware OEM to receive the appropriate microcode/firmware for their processor.”
Ubuntu wrote up an advisory about the bugs earlier this month and then later issued patches for Meltdown on January 10. Late breaking reports now suggest that some users have had issued booting their machines after installing the patch for Ubuntu 16.04 (Xenial).
SUSE has released patches for most recent SUSE Linux Enterprise versions. Those versions not yet updated are expected to have updates release shortly.
Mozilla has released new versions of Firefox with mitigations to prevent exploitation of these vulnerabilities. All secured versions begin with version number 57.
Chrome 64 is scheduled be released by Google on January 23rd and will contain mitigations to protect against exploitation. Current stable versions of Chrome contain a feature called “Site Isolation,” which can be enabled to provide mitigation by isolating websites into separate address spaces. This feature is disabled by default, but can be enabled via instructions found here.\
Microsoft has released security patches for these vulnerabilities for Microsoft Internet Explorer 11 and Microsoft Edge.
Virtualization Solution Providers:
According to Microsoft: “The majority of Azure infrastructure has already been updated to address this vulnerability. Some aspects of Azure are still being updated and require a reboot of customer VMs for the security update to take effect. Many of you have received notification in recent weeks of a planned maintenance on Azure and have already rebooted your VMs to apply the fix, and no further action by you is required.”
According to Amazon, a patched Linux AMI is available for use at the present time. Users with existing Linux AMI’s can update their instances by running “yum update kernel” to apply updates. Amazon has indicated that secured Windows AMI’s will become available as patches are issued by Windows. Amazon has not yet commented on the status of their underlying virtualization infrastructure.
Google has stated that their Google Suite applications as well as Google Cloud infrastructure has been updated to mitigate all known vulnerabilities. However, customers using their own operating systems within GCP will need to apply operating system specific patches as required in order to fully patch their instances.
Citrix has asserted that Citrix XenMobile Server and Citrix NetScaler (MPX/VPX) are not vulnerable. They have also asserted that Citrix XenApp/XenDesktop products are not vulnerable. However, their underlying operating systems may be vulnerable and users should follow patching guidelines for the operating systems on which they are running those applications.
Citrix has stated that they believe Citrix NetScaler SDX and Citrix XenServer are affected by these vulnerabilities. Citrix has released a hotfix for Citrix XenServer 7.1 LTSR CU1 and plans hotfixes for Xenserver 7.0, 7.2, and 7.3. Citrix offered the following guidance regarding hotfixes: “After applying the relevant firmware/BIOS upgrades and XenServer hotfixes, guest VMs will need to be fully shut down and started at least once after the application of relevant guest operating system updates. This will allow any corresponding security updates for the guest operating system to become fully effective.”
The terminology on Citrix’s website appears to imply that these hotfixes are mitigations and not remediation’s, stating that users will need to install firmware upgrades from their hardware vendors in order for mitigations to be fully effective.
VMWare has released patches for ESXi 5.5, 6.0, and 6.5, as well as VMWare Workstation 12.x and VMWare Fusion 8.x. VMWare has stated that VMWare versions Fusion 10.x and Worsktation 14.x are not affected by these vulnerabilities.
Alibaba has indicated that it is in the process of applying patches to remediate their platform infrastructure and expect to complete it by 24:00 January 12, 2018 Beijing time. They expect little service interruption due to functionality that allows them to shift virtual machines between infrastructure while upgrading. In some instances, virtual machines will need to be restarted, and Alibaba recommends confirming contact information within their platform in the event IT staff will need to be informed of an outage.
This patching will only affect the underlying virtualization platform, users will still be responsible for applying appropriate patches for the operating systems they are running.
That not one but four distinct groups of researchers would stumble upon a seriously esoteric series of flaws in a little-talked about microprocessor optimization technique suggests that Meltdown and Spectre may not be the last problems we hear about relating to speculative execution. At the very least, properly mitigating the underlying Spectre bugs will probably take years and require a fairly fundamental rethinking of how we build microprocessors. In the meantime, we’ll just have to pay attention to security updates and install the patches that mitigate Meltdown and Spectre as early and as often as is possible.