Kernel Side-Channel Attack using Speculative Store Bypass - CVE-2018-3639
Updated
Was this information helpful?
Was this information helpful?
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.
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.
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.
Red Hat would like to thank Ken Johnson of the Microsoft Security Response Center (MSRC) and Jann Horn of Google Project Zero (GPZ).
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 Analysis of Speculative Execution Side Channels
Speculative Execution Side Channel Mitigation
Guidance for mitigating speculative execution side-channel vulnerabilities in Azure
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.
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.
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.
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.
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.
Product | Package | Advisory/Update |
Red Hat Enterprise Linux 7 (z-stream) | kernel | RHSA-2018:1965 (x86-64 Intel, PowerPC, x86 AMD) |
Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2018:2003 |
Red Hat Enterprise Linux 7 | kernel-alt | RHSA-2018:1967 |
Red Hat Enterprise Linux 7 [5] | microcode_ctl | RHEA-2018:2299 |
Red Hat Enterprise Linux 7 | libvirt | RHSA-2018:2006 |
Red Hat Enterprise Linux 7 | qemu-kvm | RHSA-2018:2001 |
Red Hat Enterprise Linux 7 | qemu-kvm | RHSA-2018:1633 |
Red Hat Enterprise Linux 7 | openjdk 1.8.0 | RHSA-2018:1649 |
Red Hat Enterprise Linux 7 | openjdk 1.7.0 | RHSA-2018:1648 |
Red Hat Enterprise Linux 7.4 Extended Update Support [2] | kernel | RHSA-2018:1635 |
Red Hat Enterprise Linux 7.4 Extended Update Support [2], [5] | microcode_ctl | RHEA-2018:2298 |
Red Hat Enterprise Linux 7.4 Extended Update Support [2] | libvirt | RHSA-2018:1652 |
Red Hat Enterprise Linux 7.4 Extended Update Support [2] | qemu-kvm | RHSA-2018:1663 |
Red Hat Enterprise Linux 7.3 Extended Update Support [2] | kernel | RHSA-2018:1737 |
Red Hat Enterprise Linux 7.3 Extended Update Support [2], [5] | microcode_ctl | RHEA-2018:2296 |
Red Hat Enterprise Linux 7.3 Extended Update Support [2] | libvirt | RHSA-2018:1653 |
Red Hat Enterprise Linux 7.3 Extended Update Support [2] | qemu-kvm | RHSA-2018:1662 |
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support [3],[4] | kernel | RHSA-2018:1637 |
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support [3],[4], [5] | microcode_ctl | RHEA-2018:2301 |
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support [3],[4] | libvirt | RHSA-2018:1668 |
Red Hat Enterprise Linux 7.2 Update Services for SAP Solutions, & Advanced Update Support [3],[4] | qemu-kvm | RHSA-2018:1661 |
Red Hat Enterprise Linux 6 (z-stream) | kernel | RHSA-2018:1854 |
Red Hat Enterprise Linux 6 [5] | microcode_ctl | RHEA-2018:2300 |
Red Hat Enterprise Linux 6 | libvirt | RHSA-2018:1669 |
Red Hat Enterprise Linux 6 | qemu-kvm | RHSA-2018:1660 |
Red Hat Enterprise Linux 6 | openjdk 1.8.0 | RHSA-2018:1650 |
Red Hat Enterprise Linux 6 | openjdk 1.7.0 | RHSA-2018:1647 |
Red Hat Enterprise Linux 6.7 Extended Update Support [2] | kernel | RHSA-2018:1826 |
Red Hat Enterprise Linux 6.7 Extended Update Support [2], [5] | microcode_ctl | RHEA-2018:2304 |
Red Hat Enterprise Linux 6.7 Extended Update Support [2] | libvirt | RHSA-2018:1667 |
Red Hat Enterprise Linux 6.7 Extended Update Support [2] | qemu-kvm | RHSA-2018:1659 |
Red Hat Enterprise Linux 6.6 Advanced Update Support [3],[4] | kernel | RHSA-2018:1639 |
Red Hat Enterprise Linux 6.6 Advanced Update Support [3],[4], [5] | microcode_ctl | RHEA-2018:2302 |
Red Hat Enterprise Linux 6.6 Advanced Update Support [3],[4] | libvirt | RHSA-2018:1666 |
Red Hat Enterprise Linux 6.6 Advanced Update Support [3],[4] | qemu-kvm | RHSA-2018:1658 |
Red Hat Enterprise Linux 6.5 Advanced Update Support [3] | kernel | RHSA-2018:1640 |
Red Hat Enterprise Linux 6.5 Advanced Update Support [3], [5] | microcode_ctl | RHEA-2018:2303 |
Red Hat Enterprise Linux 6.5 Advanced Update Support [3] | libvirt | RHSA-2018:1665 |
Red Hat Enterprise Linux 6.5 Advanced Update Support [3] | qemu-kvm | RHSA-2018:1657 |
Red Hat Enterprise Linux 6.4 Advanced Update Support [3] | kernel | RHSA-2018:1641 |
Red Hat Enterprise Linux 6.4 Advanced Update Support [3], [5] | microcode_ctl | RHEA-2018:2297 |
Red Hat Enterprise Linux 6.4 Advanced Update Support [3] | libvirt | RHSA-2018:1664 |
Red Hat Enterprise Linux 6.4 Advanced Update Support [3] | qemu-kvm | RHSA-2018:1656 |
Red Hat Enterprise Linux 5 Extended Lifecycle Support [1] | kernel | RHSA-2018-2172 (x86 64-bit) |
Red Hat Enterprise Linux 5 Extended Lifecycle Support [1], [5] | microcode_ctl | RHEA-2018:2305 |
Red Hat Enterprise Linux 5.9 Advanced Update Support [3] | kernel | RHSA-2018:2171 (x86 64-bit) |
Red Hat Enterprise Linux 5.9 Advanced Update Support [3], [5] | microcode_ctl | RHEA-2018:2295 |
RHEL Atomic Host | kernel | Respun 22May2018 |
Red Hat Enterprise MRG 2 | kernel-rt | RHSA-2018:1642 |
Red Hat Virtualization 4 [6] | redhat-virtualization-host | RHSA-2018:1696 |
Red Hat Virtualization 4 [6] | rhvm-setup-plugins | RHSA-2018:1674 |
Red Hat Virtualization 4 [6] | qemu-kvm-rhev | RHSA-2018:2060 |
Red Hat Virtualization 4 [6] | vdsm | RHSA-2018:1675 |
Red Hat Virtualization 4 [6] | ovirt-engine | RHSA-2018:1676 |
Red Hat Virtualization 3 Extended Lifecycle Support [1], [6] | redhat-virtualization-host | RHSA-2018:1710 |
Red Hat Virtualization 3 Extended Lifecycle Support [1], [6] | rhev-hypervisor7 | RHSA-2018:1711 |
Red Hat Virtualization 3 Extended Lifecycle Support [1], [6] | qemu-kvm-rhev | RHSA-2018:1654 |
Red Hat Virtualization 3 Extended Lifecycle Support [1], [6] | vdsm | RHSA-2018:1690 |
Red Hat Virtualization 3 Extended Lifecycle Support [1], [6] | ovirt-engine | RHSA-2018:1688 |
Red Hat Virtualization 3 Extended Lifecycle Support [1], [6] | rhevm-setup-plugins | RHSA-2018:1689 |
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7 | qemu-kvm-rhev | RHSA-2018:1686 |
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7 | director images | Images have been respun |
Red Hat OpenStack Platform 8.0 (Liberty) | qemu-kvm-rhev | RHSA-2018:1646 |
Red Hat OpenStack Platform 8.0 (Liberty) | director images | Images have been respun |
Red Hat OpenStack Platform 9.0 (Mitaka) | qemu-kvm-rhev | RHSA-2018:1645 |
Red Hat OpenStack Platform 9.0 (Mitaka) | director images | Images have been respun |
Red Hat OpenStack Platform 10.0 (Newton) | qemu-kvm-rhev | RHSA-2018:1644 |
Red Hat OpenStack Platform 10.0 (Newton) | director images | Images have been respun |
Red Hat OpenStack Platform 11.0 (Ocata) | qemu-kvm-rhev | Pending |
Red Hat OpenStack Platform 11.0 (Ocata) | director images | Images have been respun |
Red Hat OpenStack Platform 12.0 (Pike) | qemu-kvm-rhev | RHSA-2018:1643 |
Red Hat OpenStack Platform 12.0 (Pike) | director images | Images have been respun |
Red Hat OpenStack Platform 12.0 (Pike) | containers | Containers have been respun |
[1] 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.
[2] 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?
[3] An active AUS subscription is required for access to this patch in RHEL AUS.
What is Advanced mission critical Update Support (AUS)?
[4] An active TUS subscription is required for access to this patch in RHEL TUS.
[5] Is CPU microcode available via the microcode_ctl package?
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:
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.
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:
Note : On RHEL-5 the mitigations are available only for 64-bit systems.
Comments