CWE-1421: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
Weakness ID: 1421
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 may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.
Extended Description
Many commodity processors have Instruction Set Architecture (ISA) features that protect software components from one another. These features can include memory segmentation, virtual memory, privilege rings, trusted execution environments, and virtual machines, among others. For example, virtual memory provides each process with its own address space, which prevents processes from accessing each other's private data. Many of these features can be used to form hardware-enforced security boundaries between software components.
Many commodity processors also share microarchitectural resources that cache (temporarily store) data, which may be confidential. These resources may be shared across processor contexts, including across SMT threads, privilege rings, or others.
When transient operations allow access to ISA-protected data in a shared microarchitectural resource, this might violate users' expectations of the ISA feature that is bypassed. For example, if transient operations can access a victim's private data in a shared microarchitectural resource, then the operations' microarchitectural side effects may correspond to the accessed data. If an attacker can trigger these transient operations and observe their side effects through a covert channel [REF-1400], then the attacker may be able to infer the victim's private data. Private data could include sensitive program data, OS/VMM data, page table data (such as memory addresses), system configuration data (see Demonstrative Example 3), or any other data that the attacker does not have the required privileges to access.
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 during hardware architecture and design if a data path allows architecturally restricted data to propagate to operations that execute before an older mis-prediction or processor event (such as an exception) is caught.
Implementation
This weakness can be introduced during system software implementation if state-sanitizing operations are not invoked when switching from one context to another, according to the hardware vendor's recommendations for mitigating the weakness.
System Configuration
This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.
Architecture and Design
This weakness can be introduced when an access control check (for example, checking page permissions) can proceed in parallel with the access operation (for example, a load) that is being checked. If the processor can allow the access operation to execute before the check completes, this race condition may allow subsequent transient operations to expose sensitive information.
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
<<put the information here>>
Medium
Demonstrative Examples
Example 1
Some processors may perform access control checks in parallel with memory read/write operations. For example, when a user-mode program attempts to read data from memory, the processor may also need to check whether the memory address is mapped into user space or kernel space. If the processor performs the access concurrently with the check, then the access may be able to transiently read kernel data before the check completes. This race condition is demonstrated in the following code snippet from [REF-1408], with additional annotations:
(bad code)
Example Language: x86 Assembly
1 ; rcx = kernel address, rbx = probe array
2 xor rax, rax # set rax to 0
3 retry:
4 mov al, byte [rcx] # attempt to read kernel memory
5 shl rax, 0xc # multiply result by page size (4KB)
6 jz retry # if the result is zero, try again
7 mov rbx, qword [rbx + rax] # transmit result over a cache covert channel
Vulnerable processors may return kernel data from a shared microarchitectural resource in line 4, for example, from the processor's L1 data cache. Since this vulnerability involves a race condition, the mov in line 4 may not always return kernel data (that is, whenever the check "wins" the race), in which case this demonstration code re-attempts the access in line 6. The accessed data is multiplied by 4KB, a common page size, to make it easier to observe via a cache covert channel after the transmission in line 7. The use of cache covert channels to observe the side effects of transient execution has been described in [REF-1408].
Example 2
Many commodity processors share microarchitectural fill buffers
between sibling hardware threads on simultaneous multithreaded (SMT)
processors. Fill buffers can serve as temporary storage for data that
passes to and from the processor's caches. Microarchitectural Fill
Buffer Data Sampling (MFBDS) is a vulnerability that can allow a
hardware thread to access its sibling's private data in a shared fill
buffer. The access may be prohibited by the processor's ISA, but MFBDS
can allow the access to occur during transient execution, in
particular during a faulting operation or an operation that triggers a
microcode assist.
More information on MFBDS can be found in [REF-1405] and [REF-1409].
Example 3
Some processors may allow access to system registers (for example,
system coprocessor registers or model-specific registers) during
transient execution. This scenario is depicted in the code snippet
below. Under ordinary operating circumstances, code in exception level
0 (EL0) is not permitted to access registers that are restricted to
EL1, such as TTBR0_EL1. However, on some processors an earlier
mis-prediction can cause the MRS instruction to transiently read the
value in an EL1 register. In this example, a conditional branch (line
2) can be mis-predicted as "not taken" while waiting for a slow load
(line 1). This allows MRS (line 3) to transiently read the value in
the TTBR0_EL1 register. The subsequent memory access (line 6) can
allow the restricted register's value to become observable, for
example, over a cache covert channel.
1 LDR X1, [X2] ; arranged to miss in the cache
2 CBZ X1, over ; This will be taken
3 MRS X3, TTBR0_EL1;
4 LSL X3, X3, #imm
5 AND X3, X3, #0xFC0
6 LDR X5, [X6,X3] ; X6 is an EL0 base address
7 over
A TSX Asynchronous Abort may allow transient operations to access architecturally restricted data, potentially exposing the data over a covert channel.
Potential Mitigations
Phase: Architecture and Design
Hardware designers may choose to engineer the processor's pipeline to prevent architecturally restricted data from being used by operations that can execute transiently.
Effectiveness: High
Phase: Architecture and Design
Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.
Effectiveness: Moderate
Note:
This can be highly effective at preventing this
weakness from being exposed across different SMT threads or different
processor cores. It is generally less practical to isolate these
resources between different contexts (for example, user and kernel)
that may execute on the same SMT thread or processor core.
Phase: Architecture and Design
Hardware designers may choose to sanitize specific microarchitectural state (for example, store buffers) when the processor transitions to a different context, such as whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize microarchitectural state according to the user or system administrator's threat model. These mitigation approaches are similar to those that address CWE-226; however, sanitizing microarchitectural state may not be the optimal or best way to mitigate this weakness on every processor design.
Effectiveness: Moderate
Note:
Sanitizing shared state on context transitions
may not be practical for all processors, especially when the amount of
shared state affected by the weakness is relatively
large. Additionally, this technique may not be practical unless there
is a synchronous transition between two processor contexts that would
allow the affected resource to be sanitized. For example, this
technique alone may not suffice to mitigate asynchronous access to a
resource that is shared by two SMT threads.
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: Architecture and Design
Software architects may design software to enforce strong isolation between different contexts. For example, kernel page table isolation (KPTI) mitigates the Meltdown vulnerability [REF-1401] by separating user-mode page tables from kernel-mode page tables, which prevents user-mode processes from using Meltdown to transiently access kernel memory [REF-1404].
Effectiveness: Limited
Note:
Isolating different contexts across a process
boundary (or another kind of architectural boundary) may only be
effective for some weaknesses.
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 may only be fully effective if it
is applied to all software that runs on the system. Also, relatively
few observed examples of this weakness have exposed data through only
a single instruction.
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: Implementation
System software can mitigate this weakness by invoking state-sanitizing operations when switching from one context to another, according to the hardware vendor's recommendations.
Effectiveness: Limited
Note:
This technique may not be able to mitigate
weaknesses that arise from resource sharing across SMT threads.
Phase: System Configuration
Some systems may allow the user to disable (for example, in the BIOS) sharing of the affected resource.
Effectiveness: Limited
Note:
Disabling resource sharing (for example, by
disabling SMT) may result in significant performance overhead.
Phase: System Configuration
Some systems may allow the user to disable (for example, in the BIOS) microarchitectural features that allow transient access to architecturally restricted data.
Effectiveness: Limited
Note:
Disabling microarchitectural features such as
predictors may result in significant performance overhead.
Phase: Patching and Maintenance
The hardware vendor may provide a patch to sanitize the affected shared microarchitectural state when the processor transitions to a different context.
Effectiveness: Moderate
Note:
This technique may not be able to mitigate
weaknesses that arise from resource sharing across SMT threads.
Phase: Patching and Maintenance
This kind of patch may not be feasible or implementable for all processors or all weaknesses.
Effectiveness: Limited
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].
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 examining publicly available patent filings, for example [REF-1405] and [REF-1406]. 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
This weakness can be detected (pre-discovery) in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label data in one context (for example, kernel data) and perform information flow analysis (or a simulation, etc.) to determine whether tainted data can appear in another context (for example, user mode). Alternatively, stale or invalid data in shared microarchitectural resources can be marked as tainted, and the taint analysis framework can identify when transient operations encounter tainted data.
Effectiveness: Moderate
Note: Automated static or dynamic taint
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 (post-discovery) 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.
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-1406], [REF-1430])
Effectiveness: Opportunistic
Note: Fuzzing may not reveal all weaknesses
in a processor specification and should be combined with
other detection methods to improve coverage.
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:
If a weakness can potentially be exploited to infer data that is accessible inside or outside the current processor context, then the weakness could map to CWE-1421 and to another CWE such as CWE-1420.
[REF-1405] Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Giorgi Maisuradze, Kaveh Razavi, Herbert Bos
and Cristiano Giuffrida. "RIDL: Rogue In-Flight Data Load". 2019-05-19.
<https://mdsattacks.com/files/ridl.pdf>. URL validated: 2024-02-13.
[REF-1401] Neta Bar Kama and
Roope Kaivola. "Hardware Security Leak Detection by Symbolic Simulation". 2021-11.
<https://ieeexplore.ieee.org/document/9617727>. URL validated: 2024-02-13.
[REF-1408] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom
and Mike Hamburg. "Meltdown: Reading Kernel Memory from User Space". 2020-05-21.
<https://meltdownattack.com/meltdown.pdf>. URL validated: 2024-02-13.
[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.
Content History
Submissions
Submission Date
Submitter
Organization
2023-09-19 (CWE 4.14, 2024-02-29)
Scott D. Constable
Intel Corporation
Contributions
Contribution Date
Contributor
Organization
2024-01-22 (CWE 4.14, 2024-02-29)
David Kaplan
AMD
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
Members of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)
Jason Oberg
Cycuity
Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)
Priya B. Iyer
Intel Corporation
Member of Microarchitectural Weaknesses Working Group
2024-01-22 (CWE 4.14, 2024-02-29)
Nicole Fern
Riscure
Member of Microarchitectural Weaknesses Working Group
More information is available — Please edit the custom filter or select a different filter.
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.
