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.
{"xhtml:p":["Many commodity processors have Instruction Set Architecture (ISA)\n\t\t\t\tfeatures that protect software components from one another. These\n\t\t\t\tfeatures can include memory segmentation, virtual memory, privilege\n\t\t\t\trings, trusted execution environments, and virtual machines, among\n\t\t\t\tothers. For example, virtual memory provides each process with its own\n\t\t\t\taddress space, which prevents processes from accessing each other's\n\t\t\t\tprivate data. Many of these features can be used to form\n\t\t\t\thardware-enforced security boundaries between software components.","When separate software components (for example, two processes) share\n\t\t\t\tmicroarchitectural predictor state across a hardware boundary, code in\n\t\t\t\tone component may be able to influence microarchitectural predictor\n\t\t\t\tbehavior in another component. If the predictor can cause transient\n\t\t\t\texecution, the shared predictor state may allow an attacker to\n\t\t\t\tinfluence transient execution in a victim, and in a manner that could\n\t\t\t\tallow the attacker to infer private data from the victim by monitoring\n\t\t\t\tobservable discrepancies (CWE-203) in a covert channel [REF-1400].","Predictor state may be shared when the processor transitions from one\n\t\t\t\tcomponent to another (for example, when a process makes a system call\n\t\t\t\tto enter the kernel). Many commodity processors have features which\n\t\t\t\tprevent microarchitectural predictions that occur before a boundary\n\t\t\t\tfrom influencing predictions that occur after the boundary.","Predictor state may also be shared between hardware threads, for\n\t\t\t\texample, sibling hardware threads on a processor that supports\n\t\t\t\tsimultaneous multithreading (SMT). This sharing may be benign if the\n\t\t\t\thardware threads are simultaneously executing in the same software\n\t\t\t\tcomponent, or it could expose a weakness if one sibling is a malicious\n\t\t\t\tsoftware component, and the other sibling is a victim software\n\t\t\t\tcomponent. Processors that share microarchitectural predictors between\n\t\t\t\thardware threads may have features which prevent microarchitectural\n\t\t\t\tpredictions that occur on one hardware thread from influencing\n\t\t\t\tpredictions that occur on another hardware thread.","Features that restrict predictor state sharing across transitions or\n\t\t\t\tbetween hardware threads may be always-on, on by default, or may\n\t\t\t\trequire opt-in from software."]}
Parent Weaknesses (ChildOf)
Common Consequences
Scope
Impact
Read Memory
Potential Mitigations
The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
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 with the SMT thread that created it, and thus the processor can enforce that each predictor entry can only be used by the SMT thread that created it. This can prevent an SMT thread from using predictor entries crafted by a malicious sibling SMT thread.
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.
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.
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 ([REF-1414]).
Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.
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.
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.
The hardware vendor may provide a patch to, for example, sanitize predictor state when the processor transitions to a different context, or to prevent predictor entries from being shared across SMT threads. A patch may also introduce new ISA that allows software to toggle a mitigation.
If a hardware feature can allow microarchitectural predictor state to be shared between contexts, SMT threads, or other architecturally defined boundaries, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.
Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.
CVE-2017-5754(Branch Target Injection, BTI, Spectre v2). Shared microarchitectural indirect branch predictor state may allow code to influence transient execution across a process, VM, or privilege boundary, potentially exposing data that is accessible beyond the boundary.
CVE-2022-0001(Branch History Injection, BHI, Spectre-BHB). Shared branch history state may allow user-mode code to influence transient execution in the kernel, potentially exposing kernel data over a covert channel.
CVE-2021-33149(RSB underflow, Retbleed). Shared return stack buffer state may allow code that executes before a prediction barrier to influence transient execution after the prediction barrier, potentially exposing data that is accessible beyond the barrier over a covert channel.
Applicable Platforms
Security Training
Train your team to recognize and prevent security threats with our comprehensive security awareness program.
Start TrainingVulnerability Scanning
Discover vulnerabilities in your applications and infrastructure before attackers do.
Scan Now