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

Public Date:
Updated -
Status
Ongoing
Impact
Important

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 is 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


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.0.

Take Action

Red Hat customers running affected versions of Red Hat products are strongly recommended to update them as soon as errata are available. Customers are urged to apply the appropriate updates immediately. These fixes also require CPU microcode/firmware updates and subscribers are advised to contact their hardware OEM vendors to receive the appropriate microcode/firmware for their processor. A kernel update, without the appropriate firmware/microcode updated for the processor, is insufficient to remediate this vulnerability.
 
The order the patches are applied is not important, but after updating firmware and hypervisors, every system/virtual machine will need to power off and restart to recognize a new hardware type.

Updates for Affected Products

ProductPackageAdvisory/Update
Red Hat Enterprise Linux 7 (z-stream)kernelRHSA-2018:1629
Red Hat Enterprise Linux 7kernel-rtRHSA-2018:1630
Red Hat Enterprise Linux 7microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 7libvirtRHSA-2018:1632
Red Hat Enterprise Linux 7qemu-kvmRHSA-2018:1633
Red Hat Enterprise Linux 7openjdk 1.8.0RHSA-2018:1649
Red Hat Enterprise Linux 7openjdk 1.7.0RHSA-2018:1648
Red Hat Enterprise Linux 7.4 Extended Update Support**kernelRHSA-2018:1635
Red Hat Enterprise Linux 7.4 Extended Update Support**microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 7.4 Extended Update Support**libvirtRHSA-2018:1652
Red Hat Enterprise Linux 7.4 Extended Update Support**qemu-kvmRHSA-2018:1663
Red Hat Enterprise Linux 7.3 Extended Update Support**kernelRHSA-2018:1636
Red Hat Enterprise Linux 7.3 Extended Update Support**microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 7.3 Extended Update Support**libvirtRHSA-2018:1653
Red Hat Enterprise Linux 7.3 Extended Update Support**qemu-kvmRHSA-2018:1662
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support***,****kernelRHSA-2018:1637
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support***,****microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support***,****libvirtRHSA-2018:1668
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support***,****qemu-kvmRHSA-2018:1661
Red Hat Enterprise Linux 6 (z-stream)kernelRHSA-2018:1651
Red Hat Enterprise Linux 6microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 6libvirtRHSA-2018:1669
Red Hat Enterprise Linux 6qemu-kvmRHSA-2018:1660
Red Hat Enterprise Linux 6openjdk 1.8.0RHSA-2018:1650
Red Hat Enterprise Linux 6openjdk 1.7.0RHSA-2018:1647
Red Hat Enterprise Linux 6.7 Extended Update Support**kernelRHSA-2018:1638
Red Hat Enterprise Linux 6.7 Extended Update Support**microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 6.7 Extended Update Support**libvirtRHSA-2018:1667
Red Hat Enterprise Linux 6.7 Extended Update Support**qemu-kvmRHSA-2018:1659
Red Hat Enterprise Linux 6.6 Advanced Update Support***,****kernelRHSA-2018:1639
Red Hat Enterprise Linux 6.6 Advanced Update Support***,****microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 6.6 Advanced Update Support***,****libvirtRHSA-2018:1666
Red Hat Enterprise Linux 6.6 Advanced Update Support***,****qemu-kvmRHSA-2018:1658
Red Hat Enterprise Linux 6.5 Advanced Update Support***kernelRHSA-2018:1640
Red Hat Enterprise Linux 6.5 Advanced Update Support***microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 6.5 Advanced Update Support***libvirtRHSA-2018:1665
Red Hat Enterprise Linux 6.5 Advanced Update Support***qemu-kvmRHSA-2018:1657
Red Hat Enterprise Linux 6.4 Advanced Update Support***kernelRHSA-2018:1641
Red Hat Enterprise Linux 6.4 Advanced Update Support***microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 6.4 Advanced Update Support***libvirtRHSA-2018:1664
Red Hat Enterprise Linux 6.4 Advanced Update Support***qemu-kvmRHSA-2018:1656
Red Hat Enterprise Linux 5 Extended Lifecycle Support*kernelPending
Red Hat Enterprise Linux 5 Extended Lifecycle Support*microcode_ctlPending manufacturer availability
Red Hat Enterprise Linux 5.9 Advanced Update Support***kernelPending
Red Hat Enterprise Linux 5.9 Advanced Update Support***microcode_ctlPending manufacturer availability
RHEL Atomic HostkernelRespun 22May2018
Red Hat Enterprise MRG 2kernel-rtRHSA-2018:1642
Red Hat Virtualization 4redhat-virtualization-hostRHSA-2018:1696
Red Hat Virtualization 4rhvm-setup-pluginsRHSA-2018:1674
Red Hat Virtualization 4qemu-kvm-rhevRHSA-2018:1655
Red Hat Virtualization 4vdsmRHSA-2018:1675
Red Hat Virtualization 4ovirt-engineRHSA-2018:1676
Red Hat Virtualization 3 Extended Lifecycle Support*redhat-virtualization-hostRHSA-2018:1710
Red Hat Virtualization 3 Extended Lifecycle Support*rhev-hypervisor7RHSA-2018:1711
Red Hat Virtualization 3 Extended Lifecycle Support*qemu-kvm-rhevRHSA-2018:1654
Red Hat Virtualization 3 Extended Lifecycle Support*vdsmRHSA-2018:1690
Red Hat Virtualization 3 Extended Lifecycle Support*ovirt-engineRHSA-2018:1688
Red Hat Virtualization 3 Extended Lifecycle Support*rhevm-setup-pluginsRHSA-2018:1689
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7qemu-kvm-rhevRHSA-2018:1686
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7director imagesImages have been respun
Red Hat OpenStack Platform 8.0 (Liberty)qemu-kvm-rhev RHSA-2018:1646
Red Hat OpenStack Platform 8.0 (Liberty)director imagesImages have been respun
Red Hat OpenStack Platform 9.0 (Mitaka)qemu-kvm-rhevRHSA-2018:1645
Red Hat OpenStack Platform 9.0 (Mitaka)director imagesImages have been respun
Red Hat OpenStack Platform 10.0 (Newton)qemu-kvm-rhevRHSA-2018:1644
Red Hat OpenStack Platform 10.0 (Newton)director imagesImages have been respun
Red Hat OpenStack Platform 11.0 (Ocata)qemu-kvm-rhevPending
Red Hat OpenStack Platform 11.0 (Ocata)director imagesImages have been respun
Red Hat OpenStack Platform 12.0 (Pike)qemu-kvm-rhevRHSA-2018:1643
Red Hat OpenStack Platform 12.0 (Pike)director imagesImages have been respun
Red Hat OpenStack Platform 12.0 (Pike)containersContainers have been respun


*An active ELS subscription is required for access to this patch.  Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

**An active EUS subscription is required for access to this patch.  Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active EUS subscription.

What is the Red Hat Enterprise Linux Extended Update Support Subscription?

***An active AUS subscription is required for access to this patch in RHEL AUS.

What is Advanced mission critical Update Support (AUS)?

****An active TUS subscription is required for access to this patch in RHEL TUS.

***** Subscribers should contact their hardware OEMs to get the most up-to-date versions of CPU microcode/firmware.

Mitigation

Red Hat recommends  customers apply the microcode/firmware update provided by your hardware or CPU vendor and also install these updated kernels as soon as possible.  Software updates can be applied independently from the hardware microcode, but will not take effect until the CPU firmware has been updated. 

Customers are advised to take a risk-based approach in mitigating this issue. Systems that require high degrees of security and trust should be addressed first, and should be isolated from untrusted systems until such time as treatments can be applied to those systems to reduce the risk of exploitation.

x86 processors from Intel and AMD offer Model Specific Registers(MSRs) which can be used to enable/disable the Speculative Store Bypass function. Using these MSRs, the new kernel updates offer the following kernel command line parameters:

  • spec_store_bypass_disable=[auto/on/off/prctl]
    default: auto
    • auto: when booting with this option, the kernel detects if the processor supports the Speculative Store Bypass(SSB) function, and selects appropriate mitigation.
    • on: It turns the Speculative Store Bypass mitigation ON. The processor will not speculatively execute load(read) instructions, before all store(write) addresses are resolved.
    • off: It turns the Speculative Store Bypass mitigation OFF. The processor will use the memory disambiguator function to speculatively execute load(read) instructions before earlier store(write) instructions.
    • prctl: It enables the Speculative Store Bypass mitigation on a per-thread basis using the prctl(2) interface.
  • nospec_store_bypass_disable:
    Disable all mitigations for the Speculative Store Bypass vulnerability.

The kernel update also adds support for the sysfs interface to report if the system processor is vulnerable to the Speculative Store Bypass issue and if corresponding mitigations are in place.

  • # cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass

For JVM and/or JIT sandboxed environments, the kernel update introduces a per process control option via prctl(2) interface. It can be used by these applications to enable or disable Speculative Store Bypass on per process basis. An application can invoke prctl(2) as:

  • prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_ENABLE, 0, 0);
    To enable the Speculative Store Bypass feature. Ie. disable the mitigation.
  • prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_DISABLE, 0, 0);
    To disable the Speculative Store Bypass feature. Ie. enable the mitigation.


Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In

13 Comments

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In

What is meant by "every system/virtual machine will need to power off and restart to recognize a new hardware type." ? "Power Off" and "Restart" are two different actions.

Is a full power off + power on required, or is a simple restart good enough?

A warm reboot should be sufficient for the kernel to pickup the new microcode after it has been deployed.

Is it me or this sentence is hard to understand? 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).

I tried the Memory Disambiguator but it didn't work ;)

Ugo: It is a little tricky to disambiguate. The processor will take an in-order stream of instructions and will execute them out-of-order as needed. At the same time, it can look ahead in the instruction stream and speculatively execute code to have some state already ready for when the program gets to that code location.

Hi , Can anyone explain me about the bug ? how to find the this bug in servers?

Hi,

You can find if your system is vulnerable to this flaw by using one of the option below;

a) Easy and Simple, click on "Diagnose" tab on this vulnerability article --> Click on "Download Detection Script", download the script on the machine and run the script. This is simple bash script. This script will give you an output if your system is vulnerable.

b) Manual method, use uname -a or rpm -q kernel to know the current kernel version and then compare it with one available in "resolve" tab, relevant to your RHEL version.

Incase you need more clarification, please open support case - http://access.redhat.com/support using your Red Hat log-in.

Hello , How we will update the kernel of all linux server, Our all servers have been registered with RHSM to cover CVE-2018-3639,CVE-2018-8897 and CVE-2018-1087 bug.

Hi,

To install kernel for CVE-2018-3639, you will need to use command " yum install kernel", please refer to - https://access.redhat.com/solutions/20366

RHSM does not have functionality to auto update the system.

Incase you need more clarification, please open support case - http://access.redhat.com/support using your Red Hat log-in.

Hello, kindly advise regarding "Red Hat Enterprise Linux 7" kernel fix for Intel, as it is not included in the list of patches Thanks

Hi,

Kernel update for RHEL 7.5 is available @ https://access.redhat.com/errata/RHSA-2018:1629. Please refer to "Resolve" tab on this article, that list errata available for RHEL 7 releases.

Incase you need more clarification, please open support case - http://access.redhat.com/support using your Red Hat log-in.

Hi,

This script (v1.0) is primarily designed to detect CVE-2018-3639 on supported Red Hat Enterprise Linux systems and kernel packages. Result may be inaccurate for other RPM based systems.

This system is vulnerable for the following reasons: * CPU microcode is not updated

When will you provide the microcode update?

thanks, Maurizio

Hi Maurizio - if you need microcode now, please contact your system's manufacturer. Red Hat does not create this software, and we do not have access to the code at this time. As the microcode is made available to us and the general public, we will again provide it to our subscribers.

What about microcode updates on Linux Virtual Machines? Is it required?

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.