| Disclosure date: 2018-05-21 Published date: 2018-05-21 |
 Severity rating:4.3 Medium |
Industry-wide severity ratings can be found in the National Vulnerability Database |
Aliases
- Variant 4
- Spectre Variant 4
- Speculative Store Buffer Bypass
Related Content
INTEL-SA-00115
Microcode Revision Guidance for INTEL-SA-00115
Details on Intel's microcode update process
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 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
Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources