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.
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
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
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)
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.
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 may 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 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.
