CWE-1421 Base Incompleto

Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

This vulnerability occurs when a processor's speculative execution (transient operations) can temporarily access restricted data from another security domain. This sensitive information can leave…

Definición

What is CWE-1421?

This vulnerability occurs when a processor's speculative execution (transient operations) can temporarily access restricted data from another security domain. This sensitive information can leave traces in shared hardware structures like CPU caches, where an attacker could potentially retrieve it using a covert channel attack.
Modern processors use hardware features like virtual memory and privilege rings to create secure boundaries between applications, operating systems, and virtual machines. These features are designed to prevent unauthorized access to sensitive data. However, underlying hardware components like CPU caches are often shared across these boundaries for performance reasons, creating a potential conflict between security design and hardware optimization. During speculative execution, the processor may temporarily bypass these security boundaries and access protected data, leaving microarchitectural footprints such as cache state changes. An attacker who can trigger this speculative access and then monitor these hardware side effects through timing analysis or other covert channels can infer the victim's confidential information. This could include private application data, kernel secrets, memory addresses, or system configuration details that should remain isolated.
Impacto en el mundo real

Real-world CVEs caused by CWE-1421

  • CVE-2017-5715

    A fault may allow transient user-mode operations to access kernel data cached in the L1D, potentially exposing the data over a covert channel.

  • CVE-2018-3615

    A fault may allow transient non-enclave operations to access SGX enclave data cached in the L1D, potentially exposing the data over a covert channel.

  • CVE-2019-1135

    A TSX Asynchronous Abort may allow transient operations to access architecturally restricted data, potentially exposing the data over a covert channel.

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

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

  2. 2

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

  3. 3

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

  4. 4

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

Ejemplo de código vulnerable

Vulnerable x86 Assembly

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 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
Ejemplo de código seguro

Secure pseudo

Seguro pseudo 
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Lista de prevención

How to prevent CWE-1421

  • 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.
  • Architecture and Design Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.
  • 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.
  • Architecture and Design The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
  • 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].
  • 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.
  • 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.
  • 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.
Señales de detección

How to detect CWE-1421

Manual Analysis Moderate

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.

Automated Analysis Moderate

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.

Automated Analysis High

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

Fuzzing Opportunistic

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

Auto-corrección de Plexicus

Plexicus detecta automáticamente CWE-1421 y abre un PR de corrección en menos de 60 segundos.

Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.

Solicitar demo Probar Plexicus gratis
Preguntas frecuentes

Frequently asked questions

¿Qué es CWE-1421?

This vulnerability occurs when a processor's speculative execution (transient operations) can temporarily access restricted data from another security domain. This sensitive information can leave traces in shared hardware structures like CPU caches, where an attacker could potentially retrieve it using a covert channel attack.

¿Qué gravedad tiene CWE-1421?

MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.

¿Qué lenguajes o plataformas se ven afectados por CWE-1421?

MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.

¿Cómo puedo prevenir CWE-1421?

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.

¿Cómo detecta y corrige Plexicus CWE-1421?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-1421 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.

¿Dónde puedo aprender más sobre CWE-1421?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/1421.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Debilidades relacionadas

Weaknesses related to CWE-1421

CWE-1420 Padre

Exposure of Sensitive Information during Transient Execution

Transient execution vulnerabilities occur when a processor speculatively runs operations that don't officially commit, potentially leaking…

CWE-1422 Hermano

Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution

This vulnerability occurs when a CPU incorrectly forwards outdated or incorrect data during speculative execution. This allows sensitive…

CWE-1423 Hermano

Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

This vulnerability occurs when separate software components, like different processes or virtual machines, share the processor's internal…

Recursos

Further reading

Listo cuando tú lo estés

Deja de pagar por desarrollador.
Empieza a cerrar el bucle.

Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.

Comenzar gratis Reservar una demo