CWE-1422: Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
Weakness ID: 1422
Vulnerability Mapping:
ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities Abstraction: BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.For users who wish to see all available information for the CWE/CAPEC entry.For users who want to customize what details are displayed.
×
Edit Custom Filter
Description
A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.
Extended Description
Software may use a variety of techniques to preserve the confidentiality of private data that is accessible within the current processor context. For example, the memory safety and type safety properties of some high-level programming languages help to prevent software written in those languages from exposing private data. As a second example, software sandboxes may co-locate multiple users' software within a single process. The processor's Instruction Set Architecture (ISA) may permit one user's software to access another user's data (because the software shares the same address space), but the sandbox prevents these accesses by using software techniques such as bounds checking.
If incorrect or stale data can be forwarded (for example, from a cache) to transient operations, then the operations' microarchitectural side effects may correspond to the data. If an attacker can trigger these transient operations and observe their side effects through a covert channel, then the attacker may be able to infer the data. For example, an attacker process may induce transient execution in a victim process that causes the victim to inadvertently access and then expose its private data via a covert channel. In the software sandbox example, an attacker sandbox may induce transient execution in its own code, allowing it to transiently access and expose data in a victim sandbox that shares the same address space.
Consequently, weaknesses that arise from incorrect/stale data forwarding might violate users' expectations of software-based memory safety and isolation techniques. If the data forwarding behavior is not properly documented by the hardware vendor, this might violate the software vendor's expectation of how the hardware should behave.
Relationships
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Nature
Type
ID
Name
ChildOf
Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Hardware Design" (CWE-1194)
Nature
Type
ID
Name
ChildOf
Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase
Note
Architecture and Design
This weakness can be introduced by data speculation techniques, or when the processor pipeline is designed to check exception conditions concurrently with other operations. This weakness can also persist after a CWE-1421 weakness has been mitigated. For example, suppose that a processor can forward stale data from a shared microarchitectural buffer to dependent transient operations, and furthermore suppose that the processor has been patched to flush the buffer on context switches. This mitigates the CWE-1421 weakness, but the stale-data forwarding behavior may persist as a CWE-1422 weakness unless this behavior is also patched.
Applicable Platforms
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages
Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems
Class: Not OS-Specific (Undetermined Prevalence)
Architectures
Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies
Class: Not Technology-Specific (Undetermined Prevalence)
Common Consequences
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope
Impact
Likelihood
Confidentiality
Technical Impact: Read Memory
Medium
Demonstrative Examples
Example 1
Faulting loads in a victim domain may trigger incorrect transient forwarding, which leaves secret-dependent traces in the microarchitectural state. Consider this code sequence example from [REF-1391].
A processor with this weakness will store the value of untrusted_arg
(which may be provided by an attacker) to the stack, which is trusted
memory. Additionally, this store operation will save this value in
some microarchitectural buffer, for example, the store buffer.
In this code sequence, trusted_ptr is dereferenced while the attacker
forces a page fault. The faulting load causes the processor to
mis-speculate by forwarding untrusted_arg as the (transient) load
result. The processor then uses untrusted_arg for the pointer
dereference. After the fault has been handled and the load has been
re-issued with the correct argument, secret-dependent information
stored at the address of trusted_ptr remains in microarchitectural
state and can be extracted by an attacker using a vulnerable code
sequence.
Example 2
Some processors try to predict when a store will forward data to a subsequent load, even when the address of the store or the load is not yet known. For example, on Intel processors this feature is called a Fast Store Forwarding Predictor [REF-1392], and on AMD processors the feature is called Predictive Store Forwarding [REF-1393]. A misprediction can cause incorrect or stale data to be forwarded from a store to a load, as illustrated in the following code snippet from [REF-1393]:
In this example, assume that the parameter idx can only be 0 or 1, and
assume that idx_array initially contains all 0s. Observe that the
assignment to v in line 4 will be array[0], regardless of whether
idx=0 or idx=1. Now suppose that an attacker repeatedly invokes fn
with idx=0 to train the store forwarding predictor to predict that the
store in line 3 will forward the data 4096 to the load idx_array[idx]
in line 4. Then, when the attacker invokes fn with idx=1 the predictor
may cause idx_array[idx] to transiently produce the incorrect value
4096, and therefore v will transiently be assigned the value
array[4096], which otherwise would not have been accessible in line 4.
Although this toy example is benign (it doesn't transmit array[4096]
over a covert channel), an attacker may be able to use similar
techniques to craft and train malicious code sequences to, for
example, read data beyond a software sandbox boundary.
A fault, microcode assist, or abort may allow transient load operations to forward malicious stale data to dependent operations executed by a victim, causing the victim to unintentionally access and potentially expose its own data over a covert channel.
A fast store forwarding predictor may allow store operations to forward incorrect data to transient load operations, potentially exposing data over a covert channel.
Potential Mitigations
Phase: Architecture and Design
The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
Effectiveness: Limited
Note: Instructions or features that constrain transient execution or suppress its side effects may impact performance.
Phase: Requirements
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.
Effectiveness: Defense in Depth
Note: Disabling specific predictors or other hardware features may result in significant performance overhead.
Phase: Requirements
Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.
Effectiveness: Moderate
Note:
Instructions or features that constrain transient
execution or suppress its side effects may impact performance.
Phase: Requirements
Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.
Effectiveness: Limited
Note:
Disabling specific predictors or other hardware
features may result in significant performance overhead.
Phase: Build and Compilation
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.
Effectiveness: Incidental
Note:
Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].
Phase: Build and Compilation
Isolate sandboxes or managed runtimes in separate address spaces (separate processes).
Effectiveness: High
Note:
Process isolation is also an effective strategy
to mitigate many other kinds of weaknesses.
Phase: Build and Compilation
Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the mis-prediction from happening at all).
Effectiveness: Moderate
Note:
When used to comprehensively mitigate a transient
execution weakness, serialization instructions can introduce
significant performance overhead.
Phase: Build and Compilation
Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads.
Effectiveness: Limited
Note:
Address masking and related software mitigation techniques have been used to harden specific code sequences that could potentially be exploited via transient execution. For example, the Linux kernel makes limited use of this technique to mitigate bounds-check bypass [REF-1390].
Phase: Build and Compilation
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, and instead generate an alternate sequence of instructions that is not affected by the weakness.
Effectiveness: Limited
Note:
This technique is only effective for software
that is compiled with this mitigation.
Phase: Documentation
If a hardware feature can allow incorrect or stale data to be forwarded to transient operations, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.
Effectiveness: High
Detection Methods
Automated Static Analysis
A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).
Effectiveness: Moderate
Note: Automated static analysis may not reveal all weaknesses in a processor
specification and should be combined with other detection methods to improve coverage.
Manual Analysis
This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state.Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.
Effectiveness: Moderate
Note: Manual analysis may not reveal all weaknesses in a processor specification
and should be combined with other detection methods to improve coverage.
Automated Analysis
Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors:
Note: This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.
Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature
Type
ID
Name
MemberOf
Category - a CWE entry that contains a set of other entries that share a common characteristic.
(this CWE ID could be used to map to real-world vulnerabilities)
Reason: Acceptable-Use
Rationale:
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities
Comments:
Use only when the weakness arises from forwarding of incorrect/stale data, and the data is not architecturally restricted (that is, the forwarded data is accessible within the current processor context).
If a weakness arises from forwarding of incorrect/stale data that is not accessible within the current processor context, then CWE-1421 may be more appropriate for the mapping task.
References
[REF-1389] Alyssa Milburn, Ke Sun
and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08.
<https://arxiv.org/abs/2203.04277>. URL validated: 2024-02-22.
[REF-1391] Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss
and Frank Piessens. "LVI : Hijacking Transient Execution through Microarchitectural Load Value Injection". 2020-01-09.
<https://lviattack.eu/lvi.pdf>. URL validated: 2024-02-04.
Description
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
