CWE-1303 describes the root of the speculative execution family of leaks. Hardware structures shared across execution contexts, such as caches and branch predictors, can violate the expected architectural isolation between those contexts.
The programmer is told that two processes or two virtual machines are isolated. The hardware quietly shares something underneath, and the isolation has a hole nobody can see from the software.
How it happens
Modern processors use out-of-order execution, speculation, prefetching, data forwarding and caching to go faster. The details of these techniques are hidden from the programmer. MITRE says that becomes a problem when the implementation results in resources being shared across supposedly isolated contexts.
Contention for a shared resource creates a covert channel. A malicious program running in one context can recover information from another by watching how the shared resource behaves. MITRE lists the resources that have been used to leak information between contexts: caches, branch prediction logic, and load or store buffers.
Speculative and out-of-order execution makes it worse by giving the attacker more control over which data is leaked through the channel.
The record's demonstrative example uses an indirect branch predictor shared between sibling SMT threads. When thread A runs an indirect branch to a target address X, the target may be temporarily stored in the predictor. A later mispredicted indirect branch in thread B could speculatively execute instructions at X, or at a location in B's address space that partially aliases X. The processor rolls back the architectural effects of the misprediction, but the memory accesses it made alter the data cache state, and the cache state is not rolled back. The cache now holds a trace that can be measured.
The word that matters in the name is non-transparent. If the extent of sharing is undocumented, MITRE notes it is extremely difficult to ensure that system assets are protected against disclosure. Nobody can reason about isolation they cannot see.
What an attacker gains
The scope is confidentiality, with consequences of reading application data and reading memory. MITRE notes that microarchitectural side channels have been used to leak specific information such as cryptographic keys and Address Space Layout Randomization (ASLR) offsets, as well as arbitrary memory.
Leaking an ASLR offset does not steal data directly, but it removes a defense that makes other attacks harder. Leaking a key or arbitrary memory is plainer: another tenant's secrets are readable.
This matters most where unrelated parties share hardware. Cloud hosts, shared build runners and multi-user machines all place mutually distrusting code on the same cores.
How to find it
The record lists no detection methods, and the weakness is a hardware design property, so most users will not find it by testing their own code. Practical angles:
- If you design hardware, document every structure shared between contexts, including caches, predictors and buffers, and state which contexts can observe each one.
- If you operate systems, track processor vendor advisories and apply the microcode and operating system updates that address microarchitectural channels.
- If you run mixed-trust workloads, ask which contexts share cores or sibling threads with which others.
- Check which timers and performance counters untrusted code can read, since those are the measuring tools for the channel.
Because the leak lives below your application, your dependency list will not show it. It is still worth keeping the software stack current so mitigations that rely on operating system or library support are present.
How to fix it
MITRE lists one mitigation, repeated for architecture and design and for requirements. Microarchitectural covert channels can be addressed with a mixture of hardware and software techniques. The record names:
- Partitioned caches, so contexts do not share cache lines.
- New barrier and flush instructions, to clear shared state when moving between contexts.
- Disabling high-resolution performance counters and timers, which makes the channel harder to measure.
These are tradeoffs. Partitioning and flushing cost performance, and removing timers can break legitimate uses. The design decision is where the trust boundary is and how much isolation it needs.
At the system level, you can reduce exposure by not scheduling mutually distrusting code on the same core or sibling thread when the data is sensitive. That is a deployment choice that follows from the weakness, rather than a quote from MITRE.
Quick check
Why does rolling back a mispredicted branch not remove the leak?
The architectural effects are undone, but the memory accesses already changed data cache state, and the cache is not rolled back.
Which shared resources has MITRE listed as leak paths?
Caches, branch prediction logic, and load or store buffers.
What is non-transparent about the sharing?
The hardware implementation hides it from the programmer, and if it is undocumented it is extremely hard to be sure assets are protected.
