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 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.
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
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?
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.
Note : On RHEL-5 the mitigations are available only for 64-bit systems.
17 Comments
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
Current Customers and Partners
Log in for full access
Log InNew to Red Hat?
Learn more about Red Hat subscriptions
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?
Hi Damon, The quick answer is: 'It depends.'
If you wanna be sure you should ask the manufacturer of your virtualization solution. In general I would say that if the firmware/bios of your cpu was updated with a fixed version, the microcode update for the virtual machines is not necessary. But VMware for example advises you to patch guest and host operating system as well as the hardware your host OS runs on.
Quick question, being a newbie at this: we are currently running 6.9 which has the variant 1-3 fixes . Since 6.10 was just released in the middle of this 'ongoing' CVE, we are assuming we will need to move to 6.10 to get variant 4 fixes when they are complete. Is this correct ... or will 6.9 have them too? Thanks!
nospec_store_bypass_disable is supposed to disable all mitigations according to the documentation, however, this parameter is nowhere in the validation script. The script contains a parameter called nospec_store_disable. If you use the first parameter the script returns that you have no updated microcode and are vulnerable (even if you do have updated microcode, since it has no idea what that variable is). If you use the parameter in the script, it reports back that you are mitigated even though you shouldn't be (possibly because it's an invalid kernel parameter and the kernel cant' read it?). Since the documentation and script don't match, which is correct?
What does "Red Hat Enterprise Linux 7 (z-stream)" really mean? Following the link to RHSA-2018:1965 has two bullets under "Security Fix(es):". The first bullet, which is for CVE-2018-3639, has a qualification of "(CVE-2018-3639, PowerPC, x86 AMD)". The second bullet has no qualifications. Under the updated packages tab, for "Red Hat Enterprise Linux for IBM z Systems 7", a similar number of updated packages is listed. Do these "Red Hat Enterprise Linux for IBM z Systems 7" packages address CVE-2018-3639 on System Z (s390x) or not?