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.

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.

Potential Impact

Demonstrative Examples

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

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

Mitigations & Prevention

Detection Methods

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

Real-World CVE Examples

Related Weaknesses