Put the processor in an infinite loop, which is then followed by instructions that should not ever be executed, since the loop is not expected to exit. After the loop, toggle an I/O bit (for oscilloscope monitoring purposes), print a console message, and reenter the loop. Note that to ensure that the loop exit is actually captured, many NOP instructions should be coded after the loop branch instruction and before the I/O bit toggle and the print statement. Margining the clock consists of varying the clock frequency until an anomaly occurs. This could be a continuous frequency change or it could be a single cycle. The single cycle method is described here. For every 1000th clock pulse, the clock cycle is shortened by 10 percent. If no effect is observed, the width is shortened by 20%. This process is continued in 10% increments up to and including 50%. Note that the cycle time may be increased as well, down to seconds per cycle. Separately, the voltage is margined. Note that the voltage could be increased or decreased. Increasing the voltage has limits, as the circuitry may not be able to withstand a drastically increased voltage. This process starts with a 5% reduction of the DC supply to the CPU chip for 5 millisecond repeated at 1KHz. If this has no effect, the process is repeated, but a 10% reduction is used. This process is repeated at 10% increments down to a 50% reduction. If no effects are observed at 5 millisecond, the whole process is repeated using a 10 millisecond pulse. If no effects are observed, the process is repeated in 10 millisecond increments out to 100 millisecond pulses. While these are suggested starting points for testing circuitry for weaknesses, the limits may need to be pushed further at the risk of device damage. See [REF-1217] for descriptions of Smart Card attacks against a clock (section 14.6.2) and using a voltage glitch (section 15.5.3).
Improper Protection Against Voltage and Clock Glitches
This vulnerability occurs when a hardware device lacks proper physical safeguards against deliberate electrical manipulation. Without dedicated protection circuits or sensors, attackers can use…
What is CWE-1247?
Real-world CVEs caused by CWE-1247
-
Lack of anti-glitch protections allows an attacker to launch a physical attack to bypass the secure boot and read protected eFuses.
-
IP communication firmware allows access to a boot shell via certain impulses
Angreiferpfad Schritt für Schritt
- 1
Identifiziere einen Codepfad, der nicht vertrauenswürdige Eingaben ohne Validierung verarbeitet.
- 2
Erzeuge eine Payload, die das unsichere Verhalten auslöst — Injection, Traversal, Overflow oder Logik-Missbrauch.
- 3
Liefere die Payload über einen normalen Request aus und beobachte die Reaktion der Anwendung.
- 4
Iteriere, bis die Antwort Daten preisgibt, Angreifer-Code ausführt oder Berechtigungen eskaliert.
Vulnerable C
Below is a representative snippet of C code that is part of the secure-boot flow. A signature of the runtime-firmware image is calculated and compared against a golden value. If the signatures match, the bootloader loads runtime firmware. If there is no match, an error halt occurs. If the underlying hardware executing this code does not contain any circuitry or sensors to detect voltage or clock glitches, an attacker might launch a fault-injection attack right when the signature check is happening (at the location marked with the comment), causing a bypass of the signature-checking process.
...
if (signature_matches) // <-Glitch Here
{
```
load_runtime_firmware();
}
else
{
do_not_load_runtime_firmware();
}
... Secure code
After bypassing secure boot, an attacker can gain access to system assets to which the attacker should not have access.
If the underlying hardware detects a voltage or clock glitch, the information can be used to prevent the glitch from being successful. How to prevent CWE-1247
- Architecture and Design / Implementation At the circuit-level, using Tunable Replica Circuits (TRCs) or special flip-flops such as Razor flip-flops helps mitigate glitch attacks. Working at the SoC or platform base, level sensors may be implemented to detect glitches. Implementing redundancy in security-sensitive code (e.g., where checks are performed)also can help with mitigation of glitch attacks.
How to detect CWE-1247
During the implementation phase where actual hardware is available, specialized hardware tools and apparatus such as ChipWhisperer may be used to check if the platform is indeed susceptible to voltage and clock glitching attacks.
Review if the protections against glitching merely transfer the attack target. For example, suppose a critical authentication routine that an attacker would want to bypass is given the protection of modifying certain artifacts from within that specific routine (so that if the routine is bypassed, one can examine the artifacts and figure out that an attack must have happened). However, if the attacker has the ability to bypass the critical authentication routine, they might also have the ability to bypass the other protection routine that checks the artifacts. Basically, depending on these kind of protections is akin to resorting to "Security by Obscurity".
Many SoCs come equipped with a built-in Dynamic Voltage and Frequency Scaling (DVFS) that can control the voltage and clocks via software alone. However, there have been demonstrated attacks (like Plundervolt and CLKSCREW) that target this DVFS [REF-1081] [REF-1082]. During the design and implementation phases, one needs to check if the interface to this power management feature is available from unprivileged SW (CWE-1256), which would make the attack very easy.
Plexicus erkennt CWE-1247 automatisch und öffnet in unter 60 Sekunden einen Fix-PR.
Codex Remedium scannt jeden Commit, identifiziert genau diese Schwachstelle und liefert einen reviewer-ready Pull Request mit dem Patch. Keine Tickets. Keine Hand-offs.
Frequently asked questions
Was ist CWE-1247?
This vulnerability occurs when a hardware device lacks proper physical safeguards against deliberate electrical manipulation. Without dedicated protection circuits or sensors, attackers can use voltage spikes or irregular clock signals to bypass security features, potentially exposing sensitive data or taking control of the system.
Wie gravierend ist CWE-1247?
MITRE hat für diese Schwachstelle keine Exploit-Wahrscheinlichkeit veröffentlicht. Behandle sie als mittlere Auswirkung, bis dein Threat Model anderes belegt.
Welche Sprachen oder Plattformen sind von CWE-1247 betroffen?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, ICS/OT, System on Chip, Power Management Hardware, Clock/Counter Hardware, Sensor Hardware.
Wie kann ich CWE-1247 verhindern?
At the circuit-level, using Tunable Replica Circuits (TRCs) or special flip-flops such as Razor flip-flops helps mitigate glitch attacks. Working at the SoC or platform base, level sensors may be implemented to detect glitches. Implementing redundancy in security-sensitive code (e.g., where checks are performed)also can help with mitigation of glitch attacks.
Wie erkennt und behebt Plexicus CWE-1247?
Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-1247 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.
Wo erfahre ich mehr über CWE-1247?
MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/1247.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.
Weaknesses related to CWE-1247
Improper Handling of Physical or Environmental Conditions
This weakness occurs when a hardware device fails to manage unexpected physical or environmental situations, whether they happen naturally…
Improper Handling of Single Event Upsets
This vulnerability occurs when hardware logic fails to properly manage single-event upsets (SEUs), which are temporary bit flips caused by…
Improper Handling of Faults that Lead to Instruction Skips
This vulnerability occurs when a hardware device lacks or incorrectly implements the necessary circuitry or sensors to detect and respond…
Improper Handling of Hardware Behavior in Exceptionally Cold Environments
This weakness occurs when a hardware device or its firmware lacks proper safeguards to maintain security functions when operated in…
Further reading
- MITRE — offizielle CWE-1247 https://cwe.mitre.org/data/definitions/1247.html
- Circuit Techniques for Dynamic Variation Tolerance https://dl.acm.org/doi/10.1145/1629911.1629915
- Razor: A Low-Power Pipeline Based on Circuit-Level Timing Speculation https://web.eecs.umich.edu/~taustin/papers/MICRO36-Razor.pdf
- Tunable Replica Circuits and Adaptive Voltage-Frequency Techniques for Dynamic Voltage, Temperature, and Aging Variation Tolerance https://ieeexplore.ieee.org/document/5205410
- FAME: Fault-attack Aware Microprocessor Extensions for Hardware Fault Detection and Software Fault Response https://dl.acm.org/doi/10.1145/2948618.2948626
- A 45 nm Resilient Microprocessor Core for Dynamic Variation Tolerance https://ieeexplore.ieee.org/document/5654663
- Bypassing Secure Boot Using Fault Injection https://www.blackhat.com/docs/eu-16/materials/eu-16-Timmers-Bypassing-Secure-Boot-Using-Fault-Injection.pdf
Schluss mit dem Bezahlen pro Entwickler.
Schließ den Kreislauf.
Plexicus ist die KI-native ASPM, die scannt, filtert, fixt, pentestet und erklärt — autonom. Unbegrenzte Entwickler, unbegrenzte Repos, Fair-Use-KI-Aktionen. Echter kostenloser Tarif, €269/mo jährlich, wenn du bereit bist.