CWE-1423: Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution
Description
Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.
- Abstraction
- BaseA weakness specific enough to point to detection and prevention methods.
- Likelihood of exploit
- Not rated by MITRE
- Status
- Incomplete
Common consequences
- Confidentiality
Read Memory
Potential mitigations
- Architecture and Design
The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
- Architecture and DesignEffectiveness: Moderate
Hardware designers may choose to use microarchitectural bits to tag predictor entries. For example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates that the predictor entry was created in kernel mode. The processor can use this bit to enforce that predictions in the current mode must have been trained in the current mode. This can prevent malicious cross-mode training, such as when user-mode software attempts to create predictor entries that influence transient execution in the kernel. Predictor entry tags can also be used to associate each predictor entry...
- Architecture and DesignEffectiveness: Moderate
Hardware designers may choose to sanitize microarchitectural predictor state (for example, branch prediction history) when the processor transitions to a different context, for example, whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize predictor state according to the user's threat model. For example, this can allow operating system software to sanitize predictor state when performing a context switch from one process to another.
- ImplementationEffectiveness: Moderate
System software can mitigate this weakness by invoking predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) when switching from one context to another, according to the hardware vendor's recommendations.
- Build and CompilationEffectiveness: Limited
If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated. One prominent example of this mitigation is retpoline ().
- Build and CompilationEffectiveness: Moderate
Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.
- Build and CompilationEffectiveness: Incidental
Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.
- System ConfigurationEffectiveness: Moderate
Some systems may allow the user to disable predictor sharing. For example, this could be a BIOS configuration, or a model-specific register (MSR) that can be configured by the operating system or virtual machine monitor.
MITRE lists 3 more mitigations on the official entry.
Related weaknesses
Parent weaknesses
CAPEC attack patterns that exploit it
CWE 4.20 links no CAPEC attack pattern to this weakness.