Speculative store bypass analysis and mitigation (CVE-2018-3639 )

Microsoft released an advisory and security update for Spectre and Meltdown, two new hardware vulnerabilities, in January 2018. In this blog post, we’ll give a technical analysis of the CVE-2018-3639 subclass of speculative execution side channel vulnerabilities known as SPECULATE Store Bypass ( SSB ). Ken Johnson of the Microsoft Security Response Center ( MSRC ) and Jann Horn of Google Project Zero ( GPZ ) independently discoveredSSB.

Security researchers and engineers who are interested in a technical analysis of SSB and the pertinent mitigations are the target audience for this post. Please see our advice for Speculative Store Bypass and our knowledge base articles on Windows Server, Windows Client, and Microsoft cloud services for more general advice.

Please take note that the information in this post is accurate at the time it was written.

TL;DR

The CPUs that are impacted by SSB, Microsoft’s assessment of the risk, and the mitigations found so far are briefly summarized below before delving into the technical details.

Overview of the Speculative Store Bypass ( SSB )

Three speculation primitives that can be used to establish the conditions for a speculative execution side channel were discussed in our blog post on mitigating such hardware vulnerabilities. These three primitives, which are exception delivery or deferral and conditional branch misprediction, offer the fundamental techniques for beginning speculative execution along a non-archaic path. Memory access misprediction is a new category of speculation primitive that includes Speculative Store Bypass ( SSB ).

A CPU optimization that enables the speculative execution of a potentially dependent load instruction ahead of an older store is what gives rise to SSB. In particular, a load can be speculatively carried out before the store if it is predicted that it wo n’t be dependent on one. If the prediction is off, stale data may be read during load reading and possibly transferred to other dependent micro-operations during speculation. This could lead to the disclosure of sensitive information and a speculative execution side channel.

Consider the following straightforward example to help you understand how this might happen. In this instance, the architectural path’s address is assumed to be equal to both RDI and RSI.

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

If the address expression computation for RDI+RCX is delayed by prior instructions, the MOV instruction on line 1 in this example may take longer to complete. If this happens, the CPU might hypothesize that the MOVZX wo n’t be reliant on the moV and might even run it before the store-performingmov. Stale data from the RS I+RCX memory may be fed to a dependent load on line 4 after being loaded into R8. By utilizing a cache-based disclosure primitive like FLUSH+RELOAD ( if RDX refers to shared memory ) or PRIME+PROBE, it is possible to observe the sensitive byte value in R8 through an additional channel. The data accessed during speculation may have left behind residual side effects in the cache by this point, which can be measured to determine the value loaded into R8. Eventually, the CPU will detect the misprediction and discard that state that was computed.

Although this example has been condensed to clarify the problem, generalizations of this idea are possible. For instance, it’s possible that there are sequences where SSB could result in a speculative out-of-bounds read, type confusion, indirect branch, etc. Additional examples of code patterns and conditions that might result in an instance of CVE-2018-3639 have been added to our revised C++ Developer Guidance for Speculative Execution Side Channels. In actuality, an attacker must recognize an instruction sequence where:

1. The sequence can be triggered through a system call by an attacker in user mode, for example.

2. A load instruction that is architecturally reliant on a previous store is included in the sequence.

3. The sensitive, non-archaic data that the load instruction reads can be used to feed a disclosure device, for example.

4. Before the load and the dependent instructions that make up the disclosure device are speculatively executed, the store instruction does not run.

We are still looking into this new vulnerability class, but we have n’t found any instruction sequences that meet all of the aforementioned requirements, and we’re not aware of any CVE-2018-3639 exploitable instances in our software right now.

It may be possible for an attacker to provide JavaScript that generates native code that meets the aforementioned requirements in the case of Just-in-Time ( JIT ) compilers, such as those used by contemporary web browsers. To make creating a side channel more challenging, Microsoft Edge, Internet Explorer, and other well-known browsers have taken steps to lessen the accuracy of timers.

Speculative Store Bypass ( SSB )Mitigations

SSB is subject to a number of mitigations. The software security models that are typically at risk and the various strategies for reducing speculative execution side channels were discussed in our previous blog post on the subject. To frame the SSB mitigation options, we will use the terminology that was previously established from that post.

relevant to models of software security

The potential relevance of SSB to the various intra-device attack scenarios that software security models typically deal with is outlined in the table below. The orange cells ( grey cells indicate not applicable ) indicate that SSB is theoretically applicable to each attack scenario, similar to CVE 2017- 5753 ( Spectre variant 1 ).

SSB speculation techniques should be avoided.

Addressing the problem as closely to the root cause as possible is one of the best ways to reduce a vulnerability, as we’ve previously noted. There are a few methods that can be applied to SSB to stop speculation techniques from using it as the basis for speculation.

Speculation barrier using instruction for serialization

Similar to CVE-2017-5753 ( Spectre variant 1 ), SSB can be reduced by using an architecturally defined instruction that serializes execution, serving as a speculation barrier. A serializing instruction can be placed between the store instruction and the load that could be speculatively executed ahead of the shop in the case of SSB ( for example, an LFENCE on x86/x64 and an SBB on the ARM ). For instance, the condensed example from this post is mitigated by adding an LFENCE to line2. The C++ Developer Guidance for Speculative Execution Side Channels contains additional details.

01: 88040F            mov [rdi+rcx],al02: 0FAEE8            lfence03: 4C0FB6040E        movzx r8,byte [rsi+rcx]04: 49C1E00C          shl r8,byte 0xc05: 428B0402          mov eax,[rdx+r8]

Disable Speculative Store Bypass ( SSBD )

A categorical mitigation for SSB can sometimes be provided by CPUs by providing facilities to prevent a speculative store bypass from happening. New hardware features that can be used by software to achieve this have been documented by AMD, ARM, and Intel. To determine whether these features are available and ready, Microsoft is collaborating with AMD, ARM, and Intel. Installing these features occasionally necessitates a firmware or microcode update. In a upcoming Windows update, Microsoft intends to offer mitigation that makes use of the updated hardware features.

generally applicable SSB mitigations

Numerous mitigations that have already been mentioned are also frequently used with SSB. These include mitigation measures like eradicating observation channels or deleting sensitive data from memory. In general, SSB can benefit from the mitigation strategies used for these two strategies that work against CVE-2017-5753 ( Spectre variant 1 ).

mitigations ‘ applicability

Understanding the connection between mitigations, speculation techniques, and the attack scenarios to which they apply is challenging due to the complexity of these issues. Tables are provided in this section to aid in the description of these connections. Our previous blog post on the subject provided a description of some of the mitigation strategies listed in the tables below.

The following tables are based on a legend:

attack-related mitigation relationships

The connection between attack scenarios and relevant mitigations is outlined in the table that follows.

Variation-related mitigation relationship

The relationship between SSB, the Spectre and Meltdown variants, and the necessary mitigations are outlined in the table below.

Putting an end to

In this article, we examined the Speculative Store Bypass ( SSB), a brand-new class of hardware vulnerabilities for side channels used for simulated execution. The risk associated with this type of vulnerability and the available mitigation options were assessed using the results of this analysis. Research into speculative execution side channels is ongoing, as we mentioned in our previous post. As we learn more, we will improve our response and mitigation strategies. We encourage researchers to contribute to 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, even though we currently believe that the risk of SSB is low.

Microsoft Security Response Center ( MSRC ) Matt Miller