CWE-1421: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
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.
- Abstraction
- BaseA weakness specific enough to point to detection and prevention methods.
- Likelihood of exploit
- Not rated by MITRE
- Status
- Incomplete
Common consequences
- Confidentiality
Read Memory
<<put the information here>>
Potential mitigations
- Architecture and DesignEffectiveness: High
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 DesignEffectiveness: Moderate
Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.
- Architecture and DesignEffectiveness: Moderate
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 DesignEffectiveness: Limited
The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
- Architecture and DesignEffectiveness: Limited
Software architects may design software to enforce strong isolation between different contexts. For example, kernel page table isolation (KPTI) mitigates the Meltdown vulnerability by separating user-mode page tables from kernel-mode page tables, which prevents user-mode processes from using Meltdown to transiently access kernel memory.
- Build and CompilationEffectiveness: Limited
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 CompilationEffectiveness: Incidental
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.
- ImplementationEffectiveness: Limited
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.
MITRE lists 5 more mitigations on the official entry.
Related weaknesses
Parent weaknesses
CAPEC attack patterns that exploit it
CWE 4.20 links no CAPEC attack pattern to this weakness.