CWE - CWE-1420: Exposure of Sensitive Information during Transient Execution (4.16)

Weakness ID: 1420

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Base 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.

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.

Description

A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.

Extended Description

When operations execute but do not commit to the processor's architectural state, this is commonly referred to as transient execution. This behavior can occur when the processor mis-predicts an outcome (such as a branch target), or when a processor event (such as an exception or microcode assist, etc.) is handled after younger operations have already executed. Operations that execute transiently may exhibit observable discrepancies (CWE-203) in covert channels [REF-1400] such as data caches. Observable discrepancies of this kind can be detected and analyzed using timing or power analysis techniques, which may allow an attacker to infer information about the operations that executed transiently. For example, the attacker may be able to infer confidential data that was accessed or used by those operations.

Transient execution weaknesses may be exploited using one of two methods. In the first method, the attacker generates a code sequence that exposes data through a covert channel when it is executed transiently (the attacker must also be able to trigger transient execution). Some transient execution weaknesses can only expose data that is accessible within the attacker's processor context. For example, an attacker executing code in a software sandbox may be able to use a transient execution weakness to expose data within the same address space, but outside of the attacker's sandbox. Other transient execution weaknesses can expose data that is architecturally inaccessible, that is, data protected by hardware-enforced boundaries such as page tables or privilege rings. These weaknesses are the subject of CWE-1421.

In the second exploitation method, the attacker first identifies a code sequence in a victim program that, when executed transiently, can expose data that is architecturally accessible within the victim's processor context. For instance, the attacker may search the victim program for code sequences that resemble a bounds-check bypass sequence (see Demonstrative Example 1). If the attacker can trigger a mis-prediction of the conditional branch and influence the index of the out-of-bounds array access, then the attacker may be able to infer the value of out-of-bounds data by monitoring observable discrepancies in a covert channel.

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:

This technique has many pitfalls. For example, InvisiSpec was an early attempt to mitigate this weakness by blocking "micro-architectural covert and side channels through the multiprocessor data cache hierarchy due to speculative loads" [REF-1417]. Commodity processors and SoCs have many covert and side channels that exist outside of the data cache hierarchy. Even when some of these channels are blocked, others (such as execution ports [REF-1418]) may allow an attacker to infer confidential data. Mitigation strategies that attempt to prevent transient execution from causing observable discrepancies also have other pitfalls, for example, see [REF-1419].

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: 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:

Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].

Phase: Build and Compilation

Isolate sandboxes or managed runtimes in separate address spaces (separate processes). For examples, see [REF-1421].

Effectiveness: High

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 prediction from happening at all).

Effectiveness: Moderate

Note:

When used to comprehensively mitigate a transient execution weakness (for example, by inserting an LFENCE after every instruction in a program), serialization instructions can introduce significant performance overhead. On the other hand, when used to mitigate only a relatively small number of high-risk code sequences, serialization instructions may have a low or negligible impact on performance.

Phase: Build and Compilation

Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.

Effectiveness: Moderate

Note:

Some CFI techniques may not be able to constrain transient execution, even though they are effective at constraining architectural execution. Or they may be able to provide some additional protection against a transient execution weakness, but without comprehensively mitigating the weakness. For example, Clang-CFI provides strong architectural CFI properties and can make some transient execution weaknesses more difficult to exploit [REF-1398].

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. One prominent example of this mitigation is retpoline ([REF-1414]).

Effectiveness: Limited

Note:

This technique may only be effective for software that is compiled with this mitigation. For some transient execution weaknesses, this technique may not be sufficient to protect software that is compiled without the affected instruction(s). For example, see CWE-1421.

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 manually inserted address masks to mitigate bounds-check bypass [REF-1390]. Compiler-based techniques have also been used to automatically harden software [REF-1425].

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: Documentation

If a hardware feature can allow incorrect operations (or correct operations with incorrect data) to execute transiently, 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	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	669	Incorrect Resource Transfer Between Spheres
ParentOf	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.	1421	Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
ParentOf	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.	1422	Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
ParentOf	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.	1423	Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

Relevant to the view "Hardware Design" (CWE-1194)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1198	Privilege Separation and Access Control Issues
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1201	Core and Compute Issues
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1202	Memory and Storage Issues
ParentOf	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.	1421	Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
ParentOf	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.	1422	Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
ParentOf	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.	1423	Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

Modes Of Introduction

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 when a computing unit (such as a CPU, GPU, accelerator, or any other processor) uses out-of-order execution, speculation, or any other microarchitectural feature that can allow microarchitectural operations to execute without committing to architectural state.

Implementation

This weakness can be introduced when sandboxes or managed runtimes are not properly isolated by using hardware-enforced boundaries. Developers of sandbox or managed runtime software should exercise caution when relying on software techniques (such as bounds checking) to prevent code in one sandbox from accessing confidential data in another sandbox. For example, an attacker sandbox may be able to trigger a processor event or mis-prediction in a manner that allows it to transiently read a victim sandbox's private data.

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

Secure programs perform bounds checking before accessing an array if the source of the array index is provided by an untrusted source such as user input. In the code below, data from array1 will not be accessed if x is out of bounds. The following code snippet is from [REF-1415]:

(bad code)

Example Language: C

if (x < array1_size)

y = array2[array1[x] * 4096];

However, if this code executes on a processor that performs conditional branch prediction the outcome of the if statement could be mis-predicted and the access on the next line will occur with a value of x that can point to an out-of-bounds location (within the program's memory).

Even though the processor does not commit the architectural effects of the mis-predicted branch, the memory accesses alter data cache state, which is not rolled back after the branch is resolved. The cache state can reveal array1[x] thereby providing a mechanism to recover the data value located at address array1 + x.

Example 2

Some managed runtimes or just-in-time (JIT) compilers may overwrite recently executed code with new code. When the instruction pointer enters the new code, the processor may inadvertently execute the stale code that had been overwritten. This can happen, for instance, when the processor issues a store that overwrites a sequence of code, but the processor fetches and executes the (stale) code before the store updates memory. Similar to the first example, the processor does not commit the stale code's architectural effects, though microarchitectural side effects can persist. Hence, confidential information accessed or used by the stale code may be inferred via an observable discrepancy in a covert channel. This vulnerability is described in more detail in [REF-1427].

Observed Examples

Reference	Description
CVE-2017-5753	Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.
CVE-2021-0089	A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.
CVE-2022-0002	Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.

Detection Methods

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. Academic researchers have demonstrated that new hardware weaknesses can be discovered by exhaustively analyzing a processor's machine clear (or nuke) conditions ([REF-1427]).

Effectiveness: Moderate

Note:

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.

Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Fuzzing

Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1428]).

Effectiveness: Opportunistic

Note:

Fuzzing may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Fuzzing

Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429]).

Effectiveness: Opportunistic

Note:

At the time of this writing, publicly available software fuzzing tools can only detect a subset of transient execution weaknesses in software (for example, [REF-1429] can only detect instances of Spectre v1) and may produce false positives.

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: Limited

Note:

At the time of this writing, publicly available software static analysis tools can only detect a subset of transient execution weaknesses in software and may produce false positives.

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:

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:

This method can be useful for detecting whether a processor is 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.	1416	Comprehensive Categorization: Resource Lifecycle Management

Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

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:

A vulnerability should only map to CWE-1420 if it cannot map to any of CWE-1420's child weaknesses. Follow this diagram:

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-1417] Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher and Josep Torrella. "InvisiSpec: making speculative execution invisible in the cache hierarchy.". 2019-05. <http://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf>. URL validated: 2024-02-14.

[REF-1418] Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida García and Nicola Tuveri. "Port Contention for Fun and Profit". 2019-05. <https://eprint.iacr.org/2018/1060.pdf>. URL validated: 2024-02-14.

[REF-1419] Mohammad Behnia, Prateek Sahu, Riccardo Paccagnella, Jiyong Yu, Zirui Zhao, Xiang Zou, Thomas Unterluggauer, Josep Torrellas, Carlos Rozas, Adam Morrison, Frank Mckeen, Fangfei Liu, Ron Gabor, Christopher W. Fletcher, Abhishek Basak and Alaa Alameldeen. "Speculative Interference Attacks: Breaking Invisible Speculation Schemes". 2021-04. <https://arxiv.org/abs/2007.11818>. URL validated: 2024-02-14.

[REF-1420] Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer and Toon Verwaest. "Spectre is here to stay: An analysis of side-channels and speculative execution". 2019-02-14. <https://arxiv.org/pdf/1902.05178.pdf>. URL validated: 2024-02-14.

[REF-1421] Intel Corporation. "Managed Runtime Speculative Execution Side Channel Mitigations". 2018-01-03. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/runtime-speculative-side-channel-mitigations.html>. URL validated: 2024-02-14.

[REF-1398] The Clang Team. "Control Flow Integrity". <https://clang.llvm.org/docs/ControlFlowIntegrity.html>. URL validated: 2024-02-13.

[REF-1414] Intel Corporation. "Retpoline: A Branch Target Injection Mitigation". 2022-08-22. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html>. URL validated: 2023-02-13.

[REF-1390] The kernel development community. "Speculation". 2020-08-16. <https://docs.kernel.org/6.6/staging/speculation.html>. URL validated: 2024-02-04.

[REF-1425] Chandler Carruth. "Speculative Load Hardening". <https://llvm.org/docs/SpeculativeLoadHardening.html>. URL validated: 2024-02-14.

[REF-1427] Hany Ragab, Enrico Barberis, Herbert Bos and Cristiano Giuffrida. "Rage Against the Machine Clear: A Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks". 2021-08. <https://www.usenix.org/system/files/sec21-ragab.pdf>. URL validated: 2024-02-14.

[REF-1428] Oleksii Oleksenko, Marco Guarnieri, Boris Köpf and Mark Silberstein. "Hide and Seek with Spectres: Efficient discovery of speculative information leaks with random testing". 2023-01-18. <https://arxiv.org/pdf/2301.07642.pdf>. URL validated: 2024-02-14.

[REF-1429] Oleksii Oleksenko, Bohdan Trach, Mark Silberstein and Christof Fetzer. "SpecFuzz: Bringing Spectre-type vulnerabilities to the surface". 2020-08. <https://www.usenix.org/system/files/sec20-oleksenko.pdf>. URL validated: 2024-02-14.

[REF-1415] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz and Yuval Yarom. "Spectre Attacks: Exploiting Speculative Execution". 2019-05. <https://spectreattack.com/spectre.pdf>. URL validated: 2024-02-14.

[REF-1400] Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11. <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. URL validated: 2024-02-13.

Content History

Submissions
Submission Date	Submitter	Organization
2023-09-19 (CWE 4.14, 2024-02-29)	Scott D. Constable	Intel Corporation
2023-09-19 (CWE 4.14, 2024-02-29)
Contributions
Contribution Date	Contributor	Organization
2024-01-22 (CWE 4.14, 2024-02-29)	David Kaplan	AMD
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett	Arm
2024-01-22 (CWE 4.14, 2024-02-29)	Members of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Jason Oberg	Cycuity
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Priya B. Iyer	Intel Corporation
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)	Nicole Fern	Riscure
2024-01-22 (CWE 4.14, 2024-02-29)	Member of Microarchitectural Weaknesses Working Group
Modifications
Modification Date	Modifier	Organization
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Mapping_Notes


	Site Map \| Terms of Use \| Manage Cookies \| Cookie Notice \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2024, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-1420: Exposure of Sensitive Information during Transient Execution

Edit Custom Filter