CWE-1420: Exposure of Sensitive Information during Transient Execution

Description:
A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.

Extended Description:
When operations execute but do not commit to the processor's
					architectural state, this is commonly referred to as transient
					execution. This behavior can occur when the processor mis-predicts an
					outcome (such as a branch target), or when a processor event (such as
					an exception or microcode assist, etc.) is handled after younger
					operations have already executed. Operations that execute transiently
					may exhibit observable discrepancies (CWE-203) in covert channels
					[REF-1400] such as data caches. Observable discrepancies of this kind
					can be detected and analyzed using timing or power analysis
					techniques, which may allow an attacker to infer information about the
					operations that executed transiently. For example, the attacker may be
					able to infer confidential data that was accessed or used by those
					operations. 
				 Transient execution weaknesses may be exploited using one of two
					methods. In the first method, the attacker gener

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-669

Consequences:
  - Confidentiality: Read Memory

Detection methods:
  - Manual Analysis: 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 occ
  - Fuzzing: 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-1428]).
  - Fuzzing: Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429]).
  - Automated Static Analysis: A variety of automated static analysis tools can identify
							potentially exploitable code sequences in software. These tools may
							perform the analysis on source code, on binary code, or on a

Mitigations:
  - [Architecture and Design] The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.
  - [Requirements] Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.
  - [Requirements] Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.
  - [Requirements] 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.

Demonstrative examples:
Secure programs perform bounds checking before accessing an array if the source of the array index is provided by an untrusted source such as user input. In the code below, data from array1 will not be accessed if x is out of bounds.  The following code snippet is from [REF-1415]:
However, if this code executes on a processor that performs
							conditional branch prediction the outcome of the if statement could be
							mis-predicted and the access on the next line will occur with a value
							of x that can point to an out-of-bounds location (within the program's
							memory). 
						 Even though the processor does not commit the architectural effects of
							the mis-predicted branch, the memory accesses alter data cache state,
							which is not rolled back after the branch is r

Some managed runtimes or just-in-time (JIT) compilers may overwrite recently executed code with new code. When the instruction pointer enters the new code, the processor may inadvertently execute the stale code that had been overwritten. This can happen, for instance, when the processor issues a store that overwrites a sequence of code, but the processor fetches and executes the (stale) code before the store updates memory. Similar to the first example, the processor does not commit the stale code's architectural effects, though microarchitectural side effects can persist. Hence, confidential information accessed or used by the stale code may be inferred via an observable discrepancy in a covert channel. This vulnerability is described in more detail in [REF-1427].

Real-world examples:
  - CVE-2017-5753: Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.
  - CVE-2021-0089: A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.
  - CVE-2022-0002: Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.