CWE-1420 describes a processor event or prediction that lets incorrect operations, or correct operations with incorrect data, execute transiently and expose data over a covert channel.
It is the parent idea behind the family of CPU speculation flaws. It matters to processor designers first, then to operating system vendors, compiler teams, browser and sandbox builders, and anyone running untrusted code beside sensitive data.
How it happens
Transient execution means operations run but never commit to the processor's architectural state. It happens when the processor mispredicts an outcome such as a branch target, or when an event such as an exception or microcode assist is handled after younger operations have already run.
The results are discarded, but the work leaves marks. MITRE says those operations can create observable discrepancies in covert channels such as data caches, which an attacker can read using timing or power analysis. From those marks the attacker can infer confidential data the transient operations touched.
Observed examples in the record:
- CVE-2017-5753: conditional branch predictors may allow operations to execute transiently after a misprediction.
- CVE-2021-0089: a machine clear triggered by self modifying code may allow incorrect operations to execute transiently.
- CVE-2022-0002: indirect branch predictors may allow incorrect operations to execute transiently after a misprediction.
What an attacker gains
The record lists one consequence, confidentiality: reading memory, with medium likelihood. The attacker does not change anything. They learn data they should not see.
How to find it
MITRE lists several methods:
- Manual analysis. In hardware, inspect processor specifications for features that may exhibit the weakness, such as microarchitectural predictors or access control checks that happen out of order.
- Fuzzing. Researchers have shown that fuzzing tools can detect it in hardware treated as a black box and in software. MITRE cautions that this is opportunistic and may not reveal every weakness, and that public tools find only a subset in software.
- Automated static analysis. Tools can identify potentially exploitable code sequences, working on source, binary or an intermediate representation.
How to fix it
There is no single fix, and MITRE is candid about the trade offs. Its effectiveness ratings tell the story.
- Isolate sandboxes and managed runtimes in separate address spaces, meaning separate processes. Rated high.
- Add serialization instructions such as LFENCE so mispredictions before the instruction cannot cause transient execution after it. Rated moderate. Used everywhere it costs real performance, but used on a small number of high risk code sequences the impact can be low.
- Use control flow integrity to constrain instructions that redirect the instruction pointer, such as indirect branches. Rated moderate.
- Expose architectural features that let software limit transient execution without disabling predictors. Rated moderate.
- Let software disable specific predictors through control registers. Rated limited, with potentially significant overhead.
- Restrict unprivileged access to high resolution timers. Defense in depth only, since attackers can use algorithms to make up for a missing time source.
- Block specific covert channels in hardware. Rated limited. MITRE gives the example that an early attempt covered the data cache hierarchy, but other channels such as execution ports remain.
For most software teams the practical steps are the first, the second where a vendor advises it, and keeping operating system, firmware and microcode updates current.
Quick check
Why are transient operations a problem if their results are discarded?
Their side effects, such as changes in cache state, remain observable through timing or power analysis, and these can reveal the data they used.
Which mitigation does MITRE rate highest?
Isolating sandboxes and managed runtimes in separate address spaces.
