Spectre and Meltdown: Why No One Should Implicitly Trust Hardware

Everyone should be wary of downloading, installing, or running unknown scripts or software (especially from questionable sources on the Internet or unexpected email attachments). The truth is, most of us have been conditioned to be a bit paranoid when running code on our machines, as we should be. This innate distrust of questionable or unknown software is a healthy outlook to have regarding security. Something many of us don’t consider, is we implicitly trust the hardware installed in our environments. Hopefully, recent events will modify the focus of that healthy skepticism to include hardware as well.

Over the past few months, the InfoSec community has been inundated with announcements surrounding hardware based vulnerabilities such as the Intel Management Engine (IME) and Intel’s Active Management Technology (AMT). The most recent report comes by way of Google’s Project Zero team and includes a pair of vulnerabilities known as Spectre and Meltdown. There has been a ton of information released over these vulnerabilities in the last week or so, which can be understandably overwhelming to many people that need actionable information.

What We Know So Far

What these vulnerabilities are:

A method for an attacker to gain read-only access to the contents of protected/privileged memory, circumventing expected privilege level checks
This read-only access could result in unexpected leaks of sensitive data such as passwords and encryption keys
The exploitation of these vulnerabilities requires the code to be run locally on a machine

What they are not:

A denial of service (DoS) attack
An attack that can be launched remotely over the network
A method to inject malicious code or corrupt memory

Mitigation Steps

Most Operating Systems now have released updates that are at least partial fixes. Apply these updates/patches after verifying your AV vendor supports the patches.
Consult with device manufacturer support for non-standard (embedded or specialized hardware) mitigations.
More research will be required to understand the true impact of these vulnerabilities and how to defend against them.

Working proof-of-concept code is published by numerous researchers, but we have not observed any weaponized exploits using these methods in the wild as of January 15, 2018.

Vulnerability Background

These vulnerabilities are a result of hardware architecture features related to Speculative Execution, CPU Caching, and Protected Memory (Kernel). See the brief descriptions below:

Speculative Execution: Essentially involves a CPU attempting to “predict the future” to increase performance or work faster. If the CPU knows that a program will make use of multiple logical branches, it will start working out the math for the branches before the program has to choose between them.

Caching: A technique used to speed up access to data stored in memory. It takes a relatively long time for the CPU to fetch data from RAM, so there exists a small amount of memory called CPU cache on the CPU itself that can be accessed very quickly. This memory gets filled with data that the CPU will need soon or is often used. What’s relevant for these vulnerabilities, is that the data output by speculative execution is usually stored in the cache, which is part of what makes speculative execution increase performance.

Protected Memory: No process running on a device should be able to access data unless it has permission to do so. This permits programs or processes to keep some of their data private from some users and allows the operating system to prevent a program from seeing data belonging to another. To access the data, a process needs to undergo a privilege check to determine if it’s allowed to see said data. The issue is, privilege checks consume CPU cycles, effectively slowing the system down. The key to these vulnerabilities is that while the CPU is waiting to verify if a process has permission to access data, speculative execution kicks in, and can access protected data prior to receiving permission to do so.

In a perfect world, this would be a secure method because the results of that speculative execution are protected at the hardware level. A process isn’t permitted to see the data until it passes the privilege check; if the check fails, then the data is discarded.

The method behind exploiting the vulnerabilities requires an understanding of CPU architecture that is beyond the scope of this article. For now, it boils down to a lower-privilege process being able to gain read-only access to protected and segmented data through a side-channel attack. So far, all exploits rely on exfiltrating data via the data cache. A value from protected memory is speculatively obtained, then an indirect load is performed that can bring that data into the cache from a different memory address, depending on one or more bits of the value to be leaked.

The Breakdown

Spectre and Meltdown are variants of the same fundamental vulnerability that affects CPUs dating back many years (Intel claims 90% of CPUs in the last 5 years). If successfully exploited, these vulnerabilities could allow attackers to gain access to data that was previously considered protected.

So far there have been three variants of the vulnerabilities identified, each given its own CVE number. Two of the variants are bundled together have been labeled Spectre, the third stand-alone labeled as Meltdown.

Spectre Variant 1: Bounds Check Bypass CVE-2017-5753
- https://nvd.nist.gov/vuln/detail/CVE-2017-5753
Spectre Variant 2: Branch Target Injection CVE-2017-5715
- https://nvd.nist.gov/vuln/detail/CVE-2017-5715
Meltdown: Rogue Data Cache Load CVE-2017-5754
- https://nvd.nist.gov/vuln/detail/CVE-2017-5754

Researchers have discovered that Meltdown affects mainly Intel processors, though some ARM-based chips have been identified as vulnerable too. The Spectre vulnerability seems to reach across almost all CPU manufacturers. With so many different pieces of hardware out there, it is extremely difficult for researchers to identify what devices are vulnerable to this type of attack. We aren’t talking about cheap IoT devices, but enterprise level hardware dating back many years.

Impact and Dangers

At the current level of understanding, the most significant threat of these vulnerabilities appears to be shared and cloud-hosted environments. Because a process running on a cloud-hosted virtual instance could theoretically have read-only access to the underlying bare metal hardware, there is a possibility to expose passwords, encryption keys, or sensitive data residing on other supposedly isolated virtual instances running on the same physical hardware.

Currently, it’s not clear what the full security ramifications of Spectre are. Meltdown is more understood in that, how it works, and how to mitigate, are well documented. The type of attacks possible with Spectre dive into areas that many security researchers are not familiar with. As such, no one is completely confident that they understand the full security implications of this type of exploit. There is a possibility that the Spectre attacks can be used for more than what is currently perceived. It’s not clear how well Spectre can be mitigated. Since we don’t fully understand the attack surface that Spectre can target, it is very hard to know, or even predict, how to defend against it. Many of the researchers behind the work are NOT convinced that software, OS level patches, or even hardware microcode updates can fully resolve the problems. The recommended mitigation steps are stop-gap solutions while the industry conducts further analysis of Spectre vulnerabilities.

Mitigation Steps

As with any major patch, update, or upgrade, it is recommended that testing be done on development or non-production machines to determine the stability of the systems before applying the changes across an organization. There have been reports of issues with applying the Windows updates, resulting in a performance loss, system errors/crashes (Blue Screen of Death), and lack of updates due to anti-virus vendor compatibility. Once the updates and upgrades are rolled out to a wider user base, we should know more about the potential impact on performance, application compatibility, and overall stability of the changes.

From a high level, follow these three main steps:

Apply the latest Operating System updates.
Enable mitigations in Windows Registry.
Apply a microcode firmware update for CPUs.

For Windows Machines, follow the steps in the Microsoft link below.

https://support.microsoft.com/en-gb/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

For Linux based machines, run the corresponding update commands on your host.

Ubuntu/Debian
- sudo apt-get update
- sudo apt-get dist-upgrade
CentOS
- sudo yum update
Fedora
- sudo dnf update

For Mac OSX machines, apply the latest OSX updates. See the Apple Support link below for more information.

https://support.apple.com/en-us/HT208394

With ICS/SCADA, non-standard, embedded, or specialized hardware, consult with the device manufacturer support for mitigation steps. There have been varying reports that these types of specialized hardware have exhibited problems upon applying patches and updates; proceed with caution.

Regardless of the operating system, a system reboot will have to be performed to apply the patches/updates.

Installing the microcode updates are trickier and should be approached with caution. Consult technical support of your chipset manufacturer for details surrounding the availability and process of these updates.

Additional Reading

Comprehensive information about both Spectre and Meltdown vulnerabilities.