CWE-1247 describes a device that has no circuitry or sensors to detect voltage and clock glitches, or has them but implemented incorrectly. Glitches are a form of fault injection: the attacker disturbs the power or clock for a moment so the processor misbehaves. It matters for secure boot, debug locks and anything else enforced in firmware on a device an attacker can touch, including ICS and OT equipment.
How it happens
Secure boot builds a chain of trust. An immutable root of trust checks the signature of the next stage against a golden value before handing over control, and so on up to the operating system. Intermediate stages configure access control and put the system in a secure state. Debug and test interfaces can also be protected by logic in hardware, firmware or both.
All of that comes down to checks in code. A glitch at the right instant can make the processor skip one.
MITRE's example is a C snippet from a secure-boot flow:
if (signature_matches) // glitch here
{
load_runtime_firmware();
}
else
{
do_not_load_runtime_firmware();
}
If the hardware has nothing to detect a voltage or clock glitch, an attacker who times a fault injection to the moment of that comparison can bypass the signature check. After bypassing secure boot, they reach assets they should not.
Two observed examples appear in the record. CVE-2019-17391 describes a lack of anti-glitch protection that allows a physical attack to bypass secure boot and read protected eFuses (Gold page). CVE-2021-33478 describes IP communication firmware that gives access to a boot shell through certain impulses (Gold page).
What an attacker gains
The record lists confidentiality, integrity and availability, gaining privileges or assuming identity, bypassing protection mechanisms, reading and modifying memory, and executing unauthorized code or commands. In short, a successful glitch on a security check can undo the whole trust model above it.
How to find it
MITRE lists several approaches:
- Manual analysis with a loop test. Put the processor in an infinite loop followed by instructions that should never run. After the loop, toggle an I/O bit so you can see whether code after the loop executed. Then apply glitches and observe.
- Specialized tools. Once real hardware exists, equipment such as ChipWhisperer can be used to check for glitch susceptibility.
- Check where the attack moves. Review whether glitch protections only transfer the target. If a critical authentication routine is protected, an attacker may glitch the code that decides whether to run it.
- Review power management. Many SoCs have Dynamic Voltage and Frequency Scaling that software can control, and that can create a way to apply glitches without physical access.
How to fix it
MITRE's mitigations for design and implementation:
- At the circuit level, use Tunable Replica Circuits or special flip-flops such as Razor flip-flops.
- At the SoC or platform level, add sensors that detect glitches.
- Add redundancy to security-sensitive code, for example where checks are performed.
The redundancy point can be shown in firmware. Checking twice, with the second check structured differently, means one skipped instruction no longer opens the door.
// Sketch of redundant checking: both must pass
if (signature_matches) {
if (signature_matches_again) {
load_runtime_firmware();
}
}
A compiler may merge identical checks, so real designs need care here. Treat this as an outline of the idea, not a finished defense.
Quick check
What is a glitch attack?
A fault injection attack that disturbs the voltage or clock for an instant so the processor skips or corrupts an operation, such as a signature check in secure boot.
Can software alone create glitches?
Possibly. MITRE notes that built-in Dynamic Voltage and Frequency Scaling can control voltage and clocks through software, which is a path worth reviewing.
