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:
- Flush or evict cache lines
- Run code that causes the processor to perform speculative operations
- Measure time to access certain cache locations known to contain secret data
- Infer what that data was from measured access times
What is speculative execution?
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.
How do Flush+Reload and Evict+Reload work?
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.
Here’s an example of cache line read times in a Flush+Reload attack. Note the downward spike indicating a faster read at one location. (Source: https://meltdownattack.com/meltdown.pdf)
What is the difference between Flush+Reload and Evict+Reload?
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.
Evict+Reload forces contention on the cache set that stores the line, causing the processor to discard the contents of that cache line. Evict+Reload techniques are typically used when access to clflush is unavailable (e.g. from JavaScript).
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).
An example of JavaScript Evict+Reload can be found here. Note that this example is not the actual technique described in the Spectre white paper. The researchers note that the accuracy of performance.now() is intentionally degraded to dissuade timing attacks, so they implemented a more high-resolution timer by spawning separate threads that repeatedly decrement a value in a shared memory location.
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.
Spectre
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.
One of the most interesting applications of Spectre is a JavaScript-based proof of concept that can access memory from within the browser process it was run. This exploit contains code that, when translated by a JIT, evaluates to a specific set of machine instructions. Execution of these JavaScript-based exploits happen within the context of the browser, and cannot read memory from outside of the browser process. However, these examples can readily be turned into weaponized exploits designed to extract secrets from within a browser’s memory space (such as credentials, certificates, etc.)
Spectre proof of concepts have been shown to work on Intel, ARM, and AMD processors.
Meltdown
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.
- Currently, Meltdown proof of concepts have only been successfully tested on Intel CPUs.
- Meltdown requires the attacker to execute code on the victim’s system itself.
- Meltdown can be used to defeat kernel address space layout randomization (KASLR).
- Meltdown can also be used to read memory from adjacent virtualized containers (Docker, LXC, OpenVZ) on the same physical host that share the same kernel.
- The Meltdown vulnerability is effectively shut down by the KAISER patch (see below).
Mitigations
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.
Update: iOS 11.2.2 also patches Safari against Spectre.
KAISER performance concerns
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.
Will the KAISER patch slow down cryptomining?
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.
Detection of Meltdown and Spectre
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.
Future
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.
Categories