2286
Academic researchers have demonstrated that this weakness can be detected in software using
software fuzzing tools ([REF-1429]).
Effectiveness = Opportunistic
At the time of this writing, publicly available software fuzzing tools can only detect a subset of
transient execution weaknesses in software (for example, [REF-1429] can only detect instances
of Spectre v1) and may produce false positives.
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 an
intermediate code representation (for example, during compilation).
Effectiveness = Limited
At the time of this writing, publicly available software static analysis tools can only detect a
subset of transient execution weaknesses in software and may produce false positives.
Automated Analysis
Software vendors can release tools that detect presence of known weaknesses 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 weakness
under test. Alternatively, some hardware vendors provide enumeration for the presence of a
weakness (or lack of a weakness). These enumeration bits can be checked and reported by
system software. For example, Linux supports these checks for many commodity processors:
$ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2
spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed
Effectiveness = High
This method can be useful for detecting whether a processor is affected by known weaknesses,
but it may not be useful for detecting unknown weaknesses.
Potential Mitigations
Phase: Architecture and Design
The hardware designer can attempt to prevent transient execution from causing observable
discrepancies in specific covert channels.
Effectiveness = Limited
This technique has many pitfalls. For example, InvisiSpec was an early attempt to mitigate this
weakness by blocking "micro-architectural covert and side channels through the multiprocessor
data cache hierarchy due to speculative loads" [REF-1417]. Commodity processors and SoCs
have many covert and side channels that exist outside of the data cache hierarchy. Even when
some of these channels are blocked, others (such as execution ports [REF-1418]) may allow an
attacker to infer confidential data. Mitigation strategies that attempt to prevent transient execution
from causing observable discrepancies also have other pitfalls, for example, see [REF-1419].
Phase: 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.
Effectiveness = Moderate
Instructions or features that constrain transient execution or suppress its side effects may impact
performance.
Phase: Requirements
CWE Version 4.14
CWE-1420: Exposure of Sensitive Information during Transient Execution
CWE-1420: Exposure of Sensitive Information during Transient Execution