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.
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
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].
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)
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.
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 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:
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 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.
