CWE-1264 describes hardware logic for error handling and security checks that incorrectly forwards data before the security check is complete. It is a chip design weakness, but its consequences reach every piece of software that runs on the affected processor.
How it happens
Many high performance on-chip bus protocols and processor data paths use separate channels for control and for data. Splitting them increases parallelism and throughput. The risk is that the control side, which carries the permission verdict, and the data side, which carries the payload, fall out of step.
If a bug lets data move on before the check completes, and that data can reach a place an attacker can observe, confidentiality is lost.
MITRE uses Meltdown as the concrete example. Data loaded from a page marked as privileged was returned to the CPU regardless of the current privilege level, for performance reasons. The assumption was that the CPU could remove all traces of that data when it handled the illegal memory access exception. That assumption proved false, because traces of the secret remained in the microarchitectural state.
The CVE recorded for this weakness is CVE-2017-5754, which covers systems with microprocessors using speculative execution and indirect branch prediction, where a local user may disclose information through a side channel.
What an attacker gains
The recorded impact is confidentiality: reading memory and reading application data. In the Meltdown case a local attacker could read data that privilege checks were supposed to keep out of reach.
How to find it
The record lists no detection methods. For chip teams, the useful question at design review is whether any path lets data leave the permission checking stage before the verdict is in. Look at error handling paths in particular, since the record names error handling logic as the place bugs hide.
For software teams, you cannot inspect your processor, but you can track which CVEs affect the hardware and operating systems you run. Inventory what you deploy so a hardware level advisory can be matched to real systems.
How to fix it
MITRE records no mitigation text. The description implies the design rule: data must not be forwarded until the security check has completed, and a failed check must leave no observable trace of the data.
- Make the check and the data release atomic from the point of view of anything observable.
- Do not rely on cleanup after the fact. The Meltdown assumption that traces could be removed later was the flaw.
- Verify the behavior on illegal access paths, not only on the successful path.
Quick check
Why was cleaning up after the exception not enough?
Traces of the secret data stayed in the microarchitectural state, where an attacker could still observe them.
