COMMON WEAKNESS ENUMERATIONIncomplete

CWE-1421

Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

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

Base

Structure

Simple

Likelihood of Exploit

Medium

Understand the problem

What is the problem?

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.

Root cause

How and when does the problem arise?

Lifecycle phase

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.

Lifecycle phase

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.

Lifecycle phase

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.

Lifecycle phase

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.

Risk

What does successful exploitation lead to?

Read Memory

Affected security scopes: Confidentiality

<<put the information here>>

Defence

How is it prevented and fixed?

Architecture and Design

Architecture and design approach

Detail
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

Architecture and Design

Architecture and design approach

Detail
Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.

Effectiveness: Moderate

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.

Architecture and Design

Architecture and design approach

Detail
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

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.

Architecture and Design

Architecture and design approach

Detail
The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.

Effectiveness: Limited

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

Architecture and Design

Architecture and design approach

Detail
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

Isolating different contexts across a process boundary (or another kind of architectural boundary) may only be effective for some weaknesses.

Build and Compilation

Build and Compilation aşaması savunması

Detail
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

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.

Build and Compilation

Build and Compilation aşaması savunması

Detail
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

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

Implementation

Implementation-phase defence

Detail
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

This technique may not be able to mitigate weaknesses that arise from resource sharing across SMT threads.

System Configuration

Secure configuration approach

Detail
Some systems may allow the user to disable (for example, in the BIOS) sharing of the affected resource.

Effectiveness: Limited

Disabling resource sharing (for example, by disabling SMT) may result in significant performance overhead.

System Configuration

Secure configuration approach

Detail
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

Disabling microarchitectural features such as predictors may result in significant performance overhead.

Patching and Maintenance

Patching and Maintenance aşaması savunması

Detail
The hardware vendor may provide a patch to sanitize the affected shared microarchitectural state when the processor transitions to a different context.

Effectiveness: Moderate

This technique may not be able to mitigate weaknesses that arise from resource sharing across SMT threads.

Patching and Maintenance

Patching and Maintenance aşaması savunması

Detail
This kind of patch may not be feasible or implementable for all processors or all weaknesses.

Effectiveness: Limited

Requirements

Security requirement

Detail
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

Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].

Verification

How is it detected?

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.

Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

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

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

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

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

Fuzzing may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.