The recently disclosed Meltdown and Spectre vulnerabilities can be viewed as privilege escalation attacks that allow an attacker to read data from memory locations that aren’t meant to be accessible. Neither of these vulnerabilities allow for code execution. However, exploits based on these vulnerabilities could allow an adversary to obtain sensitive information from memory (such as credentials, certificates, credit card information, etc.)
Exploits based on the Meltdown and Spectre vulnerabilities work by exploiting a feature of modern processors known as speculative execution (originally proposed by R. M. Tomasulo in 1967). Explained in simple terms, these exploits perform roughly the following four steps:
Speculative execution is a technique used by high-speed processors in order to increase performance by guessing likely future execution paths and prematurely executing the instructions in them.
Although the results of these speculative execution paths are discarded if program control flow fails to reach them, they can leave behind observable effects in the system. The Meltdown and Spectre white papers primarily detail techniques whereby processor cache lines are examined in order to infer the results of speculative operations. However, the Spectre paper also suggests several other methods (not necessarily related to examining the cache) to do this, and concludes that “virtually any observable effect of speculatively executed code can be leveraged to leak sensitive information”. The primary techniques used to examine processor cache lines in the Meltdown and Spectre papers are Flush+Reload and Evict+Reload.
These techniques work by measuring the time it takes to perform a memory read at an address corresponding to an evicted or flushed cache line. If, after an operation, the monitored cache line was recently accessed, data will exist in the cache and access will be fast. If the cache line was not recently accessed, the read will be slow.
The main difference between these two techniques is the mechanism used for clearing the cache.
Flush+Reload uses a dedicated machine instruction, e.g., x86’s clflush, to evict the cache lines.
Example code in the Spectre white paper (written in C) uses _mm_clflush() to perform a Flush+Reload attack (see Appendix A of the paper for details).
Although Meltdown and Spectre utilize the same basic premise, there are a few differences in the details of how they work, and what they can be used for.
A number of proof of concepts exists for Spectre.
One proof of concept uses the Linux kernel’s eBPF mechanism in order to execute a code construct in the context of the OS kernel, thus leading to similar type of privilege escalation as presented by Meltdown, but without using kernel exceptions.
Another Spectre proof of concept allows the host kernel memory space of a KVM (Linux Kernel Virtual Machine) to be exposed. This attack, however, needs admin access to the KVM guest image.
Spectre proof of concepts have been shown to work on Intel, ARM, and AMD processors.
Meltdown exploits scenarios where some CPUs allow out-of-order execution of user instructions to read kernel memory. Meltdown uses exception handlers to achieve this.
Most operating systems have already received an update that includes the KAISER patch. This patch implements a stronger isolation between kernel and user space, thus breaking the techniques that allow the Meltdown vulnerability to be exploited to read kernel memory. With KAISER in place, it is still possible to break KASLR using Meltdown exploitation techniques. However, this technique becomes non-trivial.
Since some Spectre exploits are likely to target browsers, we expect browser vendors will patch against these attacks in the near future. These patches will likely disrupt scripts’ ability to accurately record timings, and thus break the Evict+Reload portion of the attack. Depending on when you read this, Firefox may have already been patched against some of these attack vectors.
The KAISER patch is known to affect system performance. Performance impacts will be higher on software that performs a lot of system calls. Actual performance impact numbers will depend on the software and environment in question. It is likely that certain server operating environments will be affected the most. Home machines will likely not see any significant impact.
Mining, whether CPU- or GPU-based shouldn’t be affected (there shouldn’t be any syscalls in mining loops). Monero (a CPU-based miner) network hashrate appears largely unchanged since the patch.
Kernel memory violations are generated relatively infrequently by regular software. However, any process attempting to exploit Meltdown would generate thousands of such violations over a short duration. Capsule8 suggests that a system designed to monitor for an abundance of segmentation violations for kernel memory addresses (especially from the same PID) could be used to detect meltdown exploits in action.
Endgame recommends monitoring for cache timing attacks using hardware performance counters. In their blog, they examine methods to detect signs of Meltdown exploitation using TSX counters, page flush counters, and by counting last-level-cache (LLC) micro operations. They also examine how it might be possible to detect Spectre attacks by recording speculative branch execution leaks.
It is likely that software exploiting either Meltdown or Spectre will gather secrets as an intermediate step of a longer attack chain (e.g. read credentials from memory and use them to elevate a process). Although patches against Meltdown have already been released for current modern operating systems, there are plenty of legacy systems in the wild, and many users wait a long time, or don’t bother patching at all. Just as old SMB vulnerabilities were leveraged by WannaCry in the not-too-distant past, we’d expect Meltdown to be fair game in the future.
In the near future it is possible that new findings arise around speculative execution implementations, especially on the Intel platform.