Kernel Side-Channel Attack using Speculative Store Bypass - CVE-2018-3639

Red Hat has been made aware of a vulnerability that exists in modern microprocessors, requiring updates to the Linux kernel, virtualization-related components, and a microcode update. An unprivileged attacker can use this flaw to bypass restrictions in order to gain read access to privileged memory that would otherwise be inaccessible.  This issue has been assigned CVE-2018-3639 and is also referred to as “Variant 4” or “Speculative Store Bypass”.  This issue is known to affect CPUs of various microarchitectures from: AMD, ARM, IBM POWER8, and POWER9, and Intel processors.  All currently supported versions of Red Hat Enterprise Linux, Red Hat OpenShift, Red Hat Virtualization, and Red Hat OpenStack Platform are affected.

A malicious, unprivileged user could use this flaw to read privileged system memory and/or memory outside of a sandboxed environment like a web-browser or JIT execution run times.

To fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality.  At this time, microprocessor microcode will be delivered by the individual manufacturers, but at a future time Red Hat will release the tested and signed updates as we receive them.

This issue was disclosed to the public May 21, 2018.

Background Information

CVE-2018-3639 (aka “Speculative Store Bypass”) opens a new avenue (like Branch Misprediction) which can be exploited via speculative execution and cache based side channel methods to bypass security measures and access privileged memory.  This issue is similar to CVE-2017-5753 (aka “Spectre v1”), except it leverages Speculative Store Bypass memory optimization in place of Branch Misprediction used by Spectre v1.

Modern computer processors are highly complex systems. At the core they execute a sequence of instructions (aka a program) and store results into memory.

To maximize the number of instructions executed or to improve performance, processors add multiple execution cores, faster cache memory, and employs various techniques such as Out-of-Order Execution, Branch Prediction, Speculative Execution, Data Prefetching, Memory Access Reordering, Memory Disambiguation et. al. 

As instructions are executed, the processor loads(read) and stores(write) data from/to the main memory. Before Load and Store instructions can access data, they need to resolve the address given by their operand, ex.

mov    [rbx + rcx], 0x0  :  Store zero(0) into memory location [rbx + rcx]
mov    rax, [rdx + rsi]   :  Load data from memory location [rdx + rsi] into RAX register

In both cases, addresses [rbx + rcx] and [rdx + rsi] is resolved to a memory location before data can be accessed.

A typical program has many load(read) and store(write) instructions; at times both operating on the same memory address. To maintain the consistent memory state, processors use load-store-queue buffer to process load(read) and store(write) instructions. When both load and store instructions are queued, load instruction would not execute before addresses of all the store instructions in the queue are known.

Enter Speculative Store Bypass:

Modern processors can execute load/store instructions out-of-order and speculatively (when both load(read) and store(write) instructions are present in the load-store-queue).

The Memory Disambiguator(MD) predicts which of the loads do not depend on an earlier store instruction. Such load(read) instructions are then speculatively executed to load data from L1 data cache, even when the address of the earlier store is not known, thus bypassing the Store instruction. This adds to the overall performance by avoiding load latency. At the end, if the prediction was wrong and conflict between load(read) and store(write) instructions is detected, all instructions since (and including) the speculative load are re-executed.

Acknowledgements

Red Hat would like to thank Ken Johnson of the Microsoft Security Response Center (MSRC) and Jann Horn of Google Project Zero (GPZ).

Additional References

Have questions? Watch this Red Hat video about SSBD

Red Hat Blog: Speculative Store Bypass explained​

How to patch my RHV environment for Kernel Side-Channel Attack using Speculative Store Bypass CVE-2018-3639?

Is CPU microcode available via the microcode_ctl package?

Google Project Zero Variant 4 website

Intel Advisory 

Intel Analysis of Speculative Execution Side Channels

Speculative Execution Side Channel Mitigation

Guidance for mitigating speculative execution side-channel vulnerabilities in Azure

Impacted Products

Red Hat Product Security has rated CVE-2018-3639 as having a security impact of Important.

The following Red Hat product versions are impacted:

• Red Hat Enterprise Linux 5

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Atomic Host

• Red Hat Enterprise MRG 2

• Red Hat Virtualization (RHEV-H/RHV-H)

• Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7

• Red Hat OpenStack Platform 8.0 (Liberty)

• Red Hat OpenStack Platform 8.0 (Liberty) director

• Red Hat OpenStack Platform 9.0 (Mitaka)

• Red Hat OpenStack Platform 9.0 (Mitaka) director

• Red Hat OpenStack Platform 10.0 (Newton)

• Red Hat OpenStack Platform 11.0 (Ocata)

• Red Hat OpenStack Platform 12.0 (Pike)

While Red Hat's Linux Containers are not directly impacted by kernel issues, their security relies upon the integrity of the host kernel environment. Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of Red Hat containers. To protect the privacy of the containers in use, you will need to ensure that the Container host (such as Red Hat Enterprise Linux or Atomic Host) has been updated against these attacks. Red Hat has released an updated Atomic Host for this use case.

Attack Description and Impact

This Speculative Store Bypass scenario opens a side channel like Spectre variant-1. It allows load(read) instruction to access an old value from a memory location, wherein a store operation is not yet committed. It can be leveraged to read privileged system memory, if an attacker is able to control the old value at the memory location. It can also be used by processes running inside sandboxed execution environments, like a web browser, JVM or execution engines which analyse and compile source code just in time(JIT) before its execution.

Performance impact

Speculative Store Bypass or Memory Disambiguation(MD) is an optimization employed to improve efficiency of the speculative execution engine. As it allows to execute load(read) instructions without waiting on earlier store(write) instructions, it reduces the load latency and improves performance.

Enabling the Speculative Store Bypass mitigation essentially disables the Memory Disambiguation optimization. It may impact the system performance. The net performance impact will vary according to the system workload.

Regarding default configurations, Red Hat’s position favors security over performance, while allowing users the flexibility to assess their own environment and make appropriate tradeoffs through selectively enabling and disabling the various mitigations.  Red Hat is working on  additional changes  to reduce the performance impact of the initial remediation.
 
Additional performance data will be published as as it becomes available.

Diagnose your vulnerability

Determine if your system is vulnerable

Use the detection script to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well. The current version of the script is 1.4.