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.
View on MITREMany 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.
<<put the information here>>
Hardware designers may choose to engineer the processor's pipeline to prevent architecturally restricted data from being used by operations that can execute transiently.
Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.
The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
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].
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.
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.
Some systems may allow the user to disable (for example, in the BIOS) sharing of the affected resource.
Some systems may allow the user to disable (for example, in the BIOS) microarchitectural features that allow transient access to architecturally restricted data.
The hardware vendor may provide a patch to sanitize the affected shared microarchitectural state when the processor transitions to a different context.
This kind of patch may not be feasible or implementable for all processors or all weaknesses.
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.
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: $ 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
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:
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].
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. Code snippet is from [REF-1410]. See also [REF-1411].
A fault may allow transient user-mode operations to access kernel data cached in the L1D, potentially exposing the data over a covert channel.
View DetailsA fault may allow transient non-enclave operations to access SGX enclave data cached in the L1D, potentially exposing the data over a covert channel.
View DetailsA TSX Asynchronous Abort may allow transient operations to access architecturally restricted data, potentially exposing the data over a covert channel.
View DetailsCWE-1421: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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. 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.
If exploited, CWE-1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution) it can compromise Confidentiality, leading to outcomes such as Read Memory.
Recommended mitigations for CWE-1421 include: Hardware designers may choose to engineer the processor's pipeline to prevent architecturally restricted data from being used by operations that can execute transiently. Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers. The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
CWE-1421 can be detected using Automated Analysis. Combining automated tooling with manual review typically yields the best coverage.
CWE-1421 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-1421, including CVE-2017-5715, CVE-2018-3615 and CVE-2019-1135. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-1421 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.