Analysis and mitigation of speculative store bypass (CVE-2018-3639)

In January, 2018, Microsoft published an advisory and security updates for a new class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown). In this blog post, we will provide a technical analysis of an additional subclass of speculative execution side channel vulnerability known as Speculative Store Bypass (SSB) which has been assigned CVE-2018-3639. SSB was independently discovered by Ken Johnson of the Microsoft Security Response Center (MSRC) and Jann Horn (@tehjh) of Google Project Zero (GPZ).

This post is primarily geared toward security researchers and engineers who are interested in a technical analysis of SSB and the mitigations that are relevant to it. If you are interested in more general guidance, please refer to our advisory for Speculative Store Bypass and our knowledge base articles for Windows Server, Windows Client, and Microsoft cloud services.

Please note that the information in this post is current as of the date of this post.

TL;DR

Before diving into the technical details, below is a brief summary of the CPUs that are affected by SSB, Microsoft’s assessment of the risk, and the mitigations identified to date.

Speculative Store Bypass (SSB) overview

In our blog post on mitigating speculative execution side channel hardware vulnerabilities, we described three speculation primitives that can be used to create the conditions for a speculative execution side channel. These three primitives provide the fundamental methods for entering speculative execution along a non-architectural path and consist of conditional branch misprediction , indirect branch misprediction , and exception delivery or deferral. Speculative Store Bypass (SSB) belongs to a new category of speculation primitive that we refer to as memory access misprediction.

SSB arises due to a CPU optimization that can allow a potentially dependent load instruction to be speculatively executed ahead of an older store. Specifically, if a load is predicted as not being dependent on a prior store, then the load can be speculatively executed before the store. If the prediction is incorrect, this can result in the load reading stale data and possibly forwarding that data onto other dependent micro-operations during speculation. This can potentially give rise to a speculative execution side channel and the disclosure of sensitive information.

To illustrate how this might occur, it may help to consider the following simple example. In this example, RDI and RSI are assumed to be equal to the same address on the architectural path.

01: 88040F            mov [rdi+rcx],al
02: 4C0FB6040E        movzx r8,byte [rsi+rcx]
03: 49C1E00C          shl r8,byte 0xc
04: 428B0402          mov eax,[rdx+r8]

In this example, the MOV instruction on line 1 may take additional time to execute (e.g. if the computation of the address expression for RDI+RCX is waiting on prior instructions to execute). If this occurs, the CPU may predict that the MOVZX is not dependent on the MOV and may speculatively execute it ahead of the MOV that performs the store. This can result in stale data from the memory located at RSI+RCX being loaded into R8 and fed to a dependent load on line 4. If the byte value in R8 is sensitive, then it may be observed through a side channel by leveraging a cache-based disclosure primitive such as FLUSH+RELOAD (if RDX refers to shared memory) or PRIME+PROBE. The CPU will eventually detect the misprediction and discard that state that was computed, but the data that was accessed during speculation may have created residual side effects in the cache by this point that can then be measured to infer the value that was loaded into R8.

This example is simplified for the purposes of explaining the issue, but it is possible to imagine generalizations of this concept that could occur. For example, it may be possible for similar sequences to exist where SSB could give rise to a speculative out-of-bounds read, type confusion, indirect branch, and so on. We have revised our C++ Developer Guidance for Speculative Execution Side Channels to include additional examples of code patterns and conditions that could give rise to an instance of CVE-2018-3639. In practice, finding an exploitable instance of CVE-2018-3639 will require an attacker to identify an instruction sequence where:

1. The sequence is reachable across a trust boundary, e.g. an attacker in user mode can trigger the sequence in kernel mode through a system call.

2. The sequence contains a load instruction that is architecturally dependent on a prior store.

3. The stale data that is read by the load instruction is sensitive and is used in a way that can create a side channel on the non-architectural path, e.g. the data feeds a disclosure gadget.

4. The store instruction does not execute before the load and the dependent instructions that compose the disclosure gadget are speculatively executed.

While our research into this new vulnerability class is ongoing, we have not identified instruction sequences that satisfy all of the above criteria and we are currently not aware of any exploitable instances of CVE-2018-3639 in our software.

In the case of Just-in-Time (JIT) compilers, such as JavaScript JIT employed by modern web browsers, it may be possible for an attacker to supply JavaScript that produces native code that satisfies the criteria above. However, Microsoft Edge, Internet Explorer, and other major browsers have taken steps to reduce the precision of timers to increase the difficulty of successfully creating a side channel.

Mitigations for Speculative Store Bypass (SSB)

There are multiple mitigations that are applicable to SSB. In our previous blog post on mitigating speculative execution side channels, we characterized the software security models that can generally be at risk and the various tactics for mitigating speculative execution side channels. We will reuse the previously established terminology from that post to frame the mitigation options available for SSB.

Relevance to software security models

The following table summarizes the potential relevance of SSB to the various intra-device attack scenarios that software security models are typically concerned with. As with CVE-2017-5753 (Spectre variant 1), SSB is theoretically applicable to each attack scenario as indicated by the orange cells (grey cells indicate not applicable).

Preventing speculation techniques involving SSB

As we’ve noted in the past, one of the best ways to mitigate a vulnerability is by addressing the issue as close to the root cause as possible. In the case of SSB, there are a few techniques that can be used to prevent speculation techniques that rely on SSB as the speculation primitive.

Speculation barrier via serializing instruction

As with CVE-2017-5753 (Spectre variant 1), it is possible to mitigate SSB by using an instruction which is architecturally defined to serialize execution, thus acting as a speculation barrier. In the case of SSB, a serializing instruction (such as an LFENCE on x86/x64 and SSBB on ARM) can be inserted between the store instruction and the load that could be speculatively executed ahead of the store. For example, inserting an LFENCE on line 2 mitigates the simplified example from this post. Additional information can be found in the C++ Developer Guidance for Speculative Execution Side Channels.

01: 88040F            mov [rdi+rcx],al
02: 0FAEE8            lfence
03: 4C0FB6040E        movzx r8,byte [rsi+rcx]
04: 49C1E00C          shl r8,byte 0xc
05: 428B0402          mov eax,[rdx+r8]

Speculative store bypass disable (SSBD)

In some cases, CPUs can provide facilities for inhibiting a speculative store bypass from occurring and can therefore offer a categorical mitigation for SSB. AMD, ARM, and Intel have documented new hardware features that can be used by software to accomplish this. Microsoft is working with AMD, ARM, and Intel to assess the availability and readiness of these features. In some cases, these features will require a microcode or firmware update to be installed. Microsoft plans to provide a mitigation that leverages the new hardware features in a future Windows update.

Generally applicable mitigations for SSB

There are a number of previously described mitigations that are also generally applicable to SSB. These include mitigations that involve removing sensitive content from memory or removing observation channels. Generally speaking, the mitigation techniques for these two tactics that are effective against CVE-2017-5753 (Spectre variant 1) are also applicable to SSB.

Applicability of mitigations

The complex nature of these issues makes it difficult to understand the relationship between mitigations, speculation techniques, and the attack scenarios to which they apply. This section provides tables to help describe these relationships. Some of the mitigation techniques mentioned in the tables below are described in our previous blog post on this subject.

The legend for the tables that follow is:

Mitigation relationship to attack scenarios

The following table summarizes the relationship between attack scenarios and applicable mitigations.

Mitigation relationship to variants

The following table summarizes the relationship among SSB and the Spectre and Meltdown variants, and applicable mitigations.

Wrapping up

In this post, we analyzed a new class of speculative execution side channel hardware vulnerabilities known as Speculative Store Bypass (SSB). This analysis provided the basis for evaluating the risk associated with this class of vulnerability and the mitigation options that exist. As we noted in our previous post, research into speculative execution side channels is ongoing and we will continue to evolve our response and mitigations as we learn more. While we currently assess the risk of SSB as low, we encourage researchers to help further our understanding of the true risk and to report any exploitable instances of CVE-2018-3639 that may exist as part of our Speculative Execution Side Channel bounty program.

Matt Miller Microsoft Security Response Center (MSRC)