Security Software

Speculative Store Bypass / CVE-2018-3639 / INTEL-SA-00115

2018-05-21
2018-05-21
4.3

Medium

Industry-wide severity ratings can be found in the National Vulnerability Database

Critical
Medium
High
Low

Aliases

  • Variant 4
  • Spectre Variant 4
  • Speculative Store Buffer Bypass

Overview

Speculative store bypass takes advantage of the memory disambiguation predictors feature in many high-performance processors that allows loads to speculatively execute even if the address of the preceding, potentially overlapping store is unknown. If the processor predicts the load address will not overlap with the unknown address, the load may execute speculatively. If there was indeed an overlap, then the load may speculatively read stale data. The processor will eventually re-execute to correct such cases, but a malicious actor may be able to discover “confused deputy” code they can use to cause certain instructions to be executed speculatively and reveal data values in memory not normally accessible to them. Malicious actors may be able to create confused deputy code in language-based security environments (for example, a managed runtime) where a malicious actor is able to influence the generation of code.

For example, consider a scenario where key K exists. The attacker is allowed to know the value of M, but not the value of key K. X is a variable in memory. 

X = &K;    // Attacker manages to get variable with address of K stored into pointer X
<at some later point>
X = &M;      // Does a store of address of M to pointer X
Y = Array[*X & 0xFFFF]; // Dereferences address of M which is in pointer X in order to
          // load from array at index specified by M[15:0]

When the above code runs, the load from address X that occurs as part of step 3 may execute speculatively and, due to memory disambiguation, initially receive a value of address of K instead of the address of M. When this value of address of K is dereferenced, the array is speculatively accessed with an index of K[15:0] instead of M[15:0]. The CPU will later re-execute the load from address X and use M[15:0] as the index into the array. However, the cache movement caused by the earlier speculative access to the array may be analyzed by the attacker to infer information about K[15:0].

Mitigation

Processors may require different settings to implement the following mitigations. Be sure to check the CPUID and related MSRs. You can find guidance on these settings in the Deep Dive: CPUID Enumeration and Architectural MSRs.

Speculative store bypass can be mitigated through software-based approaches including process isolation and selective use of LFENCE. If software-based mitigations are not feasible, then use Speculative Store Bypass Disable (SSBD), which prevents a load from executing speculatively until the addresses of all older stores are known, although this may impact performance
 

Example scenario:

//Store N at address ‘ptrA’

*ptrA = N;

...

//expr is a high-latency expression evaluating to address ‘prtA’

*(<expr>) = P;

//Read value from ‘ptrA’

X = *ptrA; //X can read the stale value N

//Leak the value X into the cache using a gadget.

Applications

Process Isolation

This approach moves all secrets into a separate address space from untrusted code. For example, creating separate processes for different websites, so that secrets of one website are not mapped into the same address space as code from a different, possibly malicious, website. Similar techniques can be used for other runtime environments that rely on language based security to run trusted and untrusted code within the same process. This may also be useful as a defense to prevent trusted code from being manipulated to create a side channel. 

Other mitigations, such as inserting register dependencies between a vulnerable load address and the corresponding store address, may reduce the likelihood of such an attack being successful.

Using LFENCE to Control Speculative Load Execution

As speculative store bypass can only occur when a load is able to execute before an older store with an overlapping address computes the loaded address, an LFENCE between that store and the subsequent load is sufficient to prevent this case. Software should be careful to apply this mitigation judiciously to avoid unnecessary performance loss.

Software can insert an LFENCE between a store and the subsequent load (for example, the load that dereferences X in step 3) to prevent the load from executing before the previous store’s address is known. The LFENCE can also be inserted between the load and any subsequent usage of the returned data which might create a side channel (for example, the access to Array in step 3). Software should only apply this mitigation where there is a realistic risk of an exploit. Risk factors include whether the attacker can control the old value in the memory location, if there is a realistic chance of the load executing before the store address is known, and if there is a disclosure gadget that reveals the contents of sensitive memory.

Speculative Store Bypass Disable (SSBD)

If the earlier software-based mitigations are not feasible, then employing Speculative Store Bypass Disable (SSBD) will mitigate speculative store bypass. When SSBD is set, loads will not execute speculatively until the addresses of all older stores are known, ensuring that a load does not speculatively consume stale data values. 

Updates to microcode are required for SSBD. Software can disable speculative store bypass on a logical processor by setting IA32_SPEC_CTRL.SSBD to 1. On Linux*, you can enable this mitigation in applications at the thread level by via a new prctl() call: PR_SET_SPECULATION_CTRL.  This mitigation is inherited by child processes, which makes it possible to deploy from a wrapper program.

Processor Considerations

On Intel® Core™ and Intel® Xeon® processors that enable Intel® Hyper-Threading Technology and do not support enhanced IBRS, setting SSBD on a hyperthread might impact the performance of a sibling hyperthread on the same core. On these processors, we recommend clearing the SSBD MSR bit when in an idle state.
 

Front-end web developers

Front-end web developers should apply the same strategies described in the Applications section above to mitigate.

Runtime developers

Managed runtimes in sandbox environments using language-based security are vulnerable to malicious actors who can use confused deputy code to influence JIT/AOT code generation to break the sandbox isolation. 

Follow the above guidance on process isolation, judiciously implementing LFENCE, or using SSBD. Managed runtimes can use OS-provided API’s to enable and disable SSBD.

Developers of software running in an enclave

Both enclave and SMM code will behave as if SSBD is set regardless of the actual value of the IA32_SPEC_CTRL.SSBD MSR bit. The processor will ensure that a load within an enclave or SMM code does not speculatively consume stale data values due to bypassing an older store on the same logical processor.

Software Usage Guidelines

Enabling SSBD can prevent exploits based on speculative store bypass. However, this may reduce performance. Intel provides the following recommendations for use of such a mitigation. 

  • Intel recommends software set SSBD for applications and/or execution runtimes relying on language-based security mechanisms such as managed runtimes and just-in-time translators. If software is not relying on language-based security mechanisms, for example because it is using process isolation, SSBD may not be needed. 
  • Intel is currently not aware of any practical exploit for Operating Systems, Virtual Machine Monitors, or other applications that do not rely on language-based security.  Intel encourages its users to consider their particular security needs in determining whether to set SSBD outside context of language-based security mechanisms.
     

OS and driver developers

We are currently not aware of any practical exploit for Operating Systems (OS), Virtual Machine Monitors (VMMs), or other applications that do not rely on language-based security. To minimize performance impact, we do not currently recommend setting SSBD for OSes, VMMs, or applications that do not rely on language-based security.

VMMs should allow guests to determine whether to enable SSBD mitigation by providing direct guest access to IA32_SPEC_CTRL.

OSes should provide an API through which a process can request to be protected by SSBD mitigation.

Linux*

Kernel Guidance for Linux systems can be found in Mitigation Overview for Potential Side-Channel Cache Exploits in Linux*.

Windows*

Microsoft plans to provide a mitigation that leverages the new hardware features in a future Windows* update. Please refer to Microsoft’s public blog.

UEFI Firmware

No changes to UEFI or coreboot are currently planned.

SMM code will behave as if speculative store bypass disable (SSBD) is set regardless of the actual value of the MSR bit. The processor will ensure that a load within SMM code does not speculatively consume stale data values due to bypassing an older store on the same logical processor.

Virtual machine monitor (VMM) developers

Virtual machine monitor developers should implement the same strategies described in the OS and driver developers section to mitigate.

References


Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software, or service activation. Performance varies depending on system configuration. Check with your system manufacturer or retailer or learn more at www.intel.com.

All information provided here is subject to change without notice. Contact your Intel representative to obtain the latest Intel product specifications and roadmaps.

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors.

Performance tests, such as SYSmark and MobileMark, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. For more complete information visit www.intel.com/benchmarks.

Performance results are based on testing as of dates shown in configurations and may not reflect all publicly available​ updates. No product or component can be absolutely secure.

The products and services described may contain defects or errors known as errata which may cause deviations from published specifications. Current characterized errata are available on request.

Intel provides these materials as-is, with no express or implied warranties.

No product or component can be absolutely secure.

Intel, the Intel logo, Intel Core, Intel Atom, Intel Xeon, Intel Xeon Phi, Intel® C Compiler, Intel Software Guard Extensions, and Intel® Trusted Execution Engine are trademarks of Intel Corporation in the U.S. and/or other countries.

*Other names and brands may be claimed as the property of others.