{"@ID": "1247", "@Name": "Improper Protection Against Voltage and Clock Glitches", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Stable", "Description": "The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.", "Extended_Description": {"xhtml:p": "A device might support features such as secure boot which are supplemented with hardware and firmware support. This involves establishing a chain of trust, starting with an immutable root of trust by checking the signature of the next stage (culminating with the OS and runtime software) against a golden value before transferring control. The intermediate stages typically set up the system in a secure state by configuring several access control settings. Similarly, security logic for exercising a debug or testing interface may be implemented in hardware, firmware, or both. A device needs to guard against fault attacks such as voltage glitches and clock glitches that an attacker may employ in an attempt to compromise the system."}, "Related_Weaknesses": {"Related_Weakness": {"@Nature": "ChildOf", "@CWE_ID": "1384", "@View_ID": "1000", "@Ordinal": "Primary"}}, "Weakness_Ordinalities": {"Weakness_Ordinality": {"Ordinality": "Primary"}}, "Applicable_Platforms": {"Language": {"@Class": "Not Language-Specific", "@Prevalence": "Undetermined"}, "Operating_System": {"@Class": "Not OS-Specific", "@Prevalence": "Undetermined"}, "Architecture": {"@Class": "Not Architecture-Specific", "@Prevalence": "Undetermined"}, "Technology": [{"@Class": "ICS/OT", "@Prevalence": "Undetermined"}, {"@Class": "System on Chip", "@Prevalence": "Undetermined"}, {"@Name": "Power Management Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Clock/Counter Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Sensor Hardware", "@Prevalence": "Undetermined"}]}, "Modes_Of_Introduction": {"Introduction": {"Phase": "Operation"}}, "Common_Consequences": {"Consequence": {"Scope": ["Confidentiality", "Integrity", "Availability", "Access Control"], "Impact": ["Gain Privileges or Assume Identity", "Bypass Protection Mechanism", "Read Memory", "Modify Memory", "Execute Unauthorized Code or Commands"]}}, "Detection_Methods": {"Detection_Method": [{"Method": "Manual Analysis", "Description": {"xhtml:p": ["Put the processor in an infinite\n\t\t\tloop, which is then followed by instructions\n\t\t\tthat should not ever be executed, since the\n\t\t\tloop is not expected to exit.  After the loop,\n\t\t\ttoggle an I/O bit (for oscilloscope monitoring\n\t\t\tpurposes), print a console message, and\n\t\t\treenter the loop.  Note that to ensure that\n\t\t\tthe loop exit is actually captured, many NOP\n\t\t\tinstructions should be coded after the loop\n\t\t\tbranch instruction and before the I/O bit\n\t\t\ttoggle and the print statement.", "Margining the clock consists of varying the clock\n\t\t\tfrequency until an anomaly occurs. This could be a\n\t\t\tcontinuous frequency change or it could be a single\n\t\t\tcycle. The single cycle method is described here. For\n\t\t\tevery 1000th clock pulse, the clock cycle is shortened by\n\t\t\t10 percent. If no effect is observed, the width is\n\t\t\tshortened by 20%. This process is continued in 10%\n\t\t\tincrements up to and including 50%. Note that the cycle\n\t\t\ttime may be increased as well, down to seconds per\n\t\t\tcycle.", "Separately, the voltage is margined. Note that\n\t\t\tthe voltage could be increased or decreased. Increasing\n\t\t\tthe voltage has limits, as the circuitry may not be able\n\t\t\tto withstand a drastically increased voltage. This process\n\t\t\tstarts with a 5% reduction of the DC supply to the CPU\n\t\t\tchip for 5 millisecond repeated at 1KHz. If this has no\n\t\t\teffect, the process is repeated, but a 10% reduction is\n\t\t\tused. This process is repeated at 10% increments down to a\n\t\t\t50% reduction. If no effects are observed at 5\n\t\t\tmillisecond, the whole process is repeated using a 10\n\t\t\tmillisecond pulse. If no effects are observed, the process\n\t\t\tis repeated in 10 millisecond increments out to 100\n\t\t\tmillisecond pulses.", "While these are suggested starting points for\n\t\t\ttesting circuitry for weaknesses, the limits may need to\n\t\t\tbe pushed further at the risk of device damage. See\n\t\t\t[REF-1217] for descriptions of Smart Card attacks against\n\t\t\ta clock (section 14.6.2) and using a voltage glitch\n\t\t\t(section 15.5.3)."]}, "Effectiveness": "Moderate"}, {"Method": "Dynamic Analysis with Manual Results Interpretation", "Description": "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."}, {"Method": "Architecture or Design Review", "Description": "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\"."}, {"Method": "Architecture or Design Review", "Description": "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."}]}, "Potential_Mitigations": {"Mitigation": {"Phase": ["Architecture and Design", "Implementation"], "Description": {"xhtml:p": "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."}}}, "Demonstrative_Examples": {"Demonstrative_Example": {"@Demonstrative_Example_ID": "DX-234", "Intro_Text": "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.", "Example_Code": [{"@Nature": "Bad", "@Language": "C", "xhtml:br": [null, null, null, null, null, null, null, null, null], "xhtml:div": [{"@style": "margin-left:1em;", "xhtml:br": null, "#text": "load_runtime_firmware();"}, {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "do_not_load_runtime_firmware();"}], "#text": "...\n            if (signature_matches)  // <-Glitch Here\n            {\n\t\t\t\n            }\n            else\n            {\n\t\t\t\n            }\n            \t\n            ..."}, {"@Nature": "Good", "@Language": "Other", "xhtml:div": "If the underlying hardware detects a voltage or clock glitch, the information can be used to prevent the glitch from being successful."}], "Body_Text": "After bypassing secure boot, an attacker can gain access to system assets to which the attacker should not have access."}}, "Observed_Examples": {"Observed_Example": [{"Reference": "CVE-2019-17391", "Description": "Lack of anti-glitch protections allows an attacker to launch a physical attack to bypass the secure boot and read protected eFuses.", "Link": "https://www.cve.org/CVERecord?id=CVE-2019-17391"}, {"Reference": "CVE-2021-33478", "Description": "IP communication firmware allows access to a boot shell via certain impulses", "Link": "https://www.cve.org/CVERecord?id=CVE-2021-33478"}]}, "Functional_Areas": {"Functional_Area": ["Power", "Clock"]}, "Related_Attack_Patterns": {"Related_Attack_Pattern": [{"@CAPEC_ID": "624"}, {"@CAPEC_ID": "625"}]}, "References": {"Reference": [{"@External_Reference_ID": "REF-1061"}, {"@External_Reference_ID": "REF-1062"}, {"@External_Reference_ID": "REF-1063"}, {"@External_Reference_ID": "REF-1064"}, {"@External_Reference_ID": "REF-1065"}, {"@External_Reference_ID": "REF-1066"}, {"@External_Reference_ID": "REF-1217", "@Section": "14.6.2 Security Evolution, page 291"}, {"@External_Reference_ID": "REF-1217", "@Section": "15.5.3 Glitching, page 317"}, {"@External_Reference_ID": "REF-1081"}, {"@External_Reference_ID": "REF-1082"}, {"@External_Reference_ID": "REF-1285"}, {"@External_Reference_ID": "REF-1286", "@Section": "1.2 / 4"}]}, "Mapping_Notes": {"Usage": "Allowed", "Rationale": "This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.", "Comments": "Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.", "Reasons": {"Reason": {"@Type": "Acceptable-Use"}}}, "Content_History": {"Submission": {"Submission_Name": "Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi", "Submission_Organization": "Intel Corporation", "Submission_Date": "2020-02-12", "Submission_Version": "4.0", "Submission_ReleaseDate": "2020-02-24"}, "Modification": [{"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2020-08-20", "Modification_Version": "4.2", "Modification_ReleaseDate": "2020-08-20", "Modification_Comment": "updated Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, Related_Attack_Patterns"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2020-12-10", "Modification_Version": "4.3", "Modification_ReleaseDate": "2020-12-10", "Modification_Comment": "updated Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2021-03-15", "Modification_Version": "4.4", "Modification_ReleaseDate": "2021-03-15", "Modification_Comment": "updated Functional_Areas"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2021-10-28", "Modification_Version": "4.6", "Modification_ReleaseDate": "2021-10-28", "Modification_Comment": "updated Description, Detection_Factors, Name, References, Weakness_Ordinalities"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2022-04-28", "Modification_Version": "4.7", "Modification_ReleaseDate": "2022-04-28", "Modification_Comment": "updated Applicable_Platforms, Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2022-06-28", "Modification_Version": "4.8", "Modification_ReleaseDate": "2022-06-28", "Modification_Comment": "updated Applicable_Platforms, Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2022-10-13", "Modification_Version": "4.9", "Modification_ReleaseDate": "2022-10-13", "Modification_Comment": "updated Demonstrative_Examples, References"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-01-31", "Modification_Version": "4.10", "Modification_ReleaseDate": "2023-01-31", "Modification_Comment": "updated Applicable_Platforms, Related_Attack_Patterns, Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-04-27", "Modification_Version": "4.11", "Modification_ReleaseDate": "2023-04-27", "Modification_Comment": "updated References, Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-06-29", "Modification_Version": "4.12", "Modification_ReleaseDate": "2023-06-29", "Modification_Comment": "updated Mapping_Notes"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-10-26", "Modification_Version": "4.13", "Modification_ReleaseDate": "2023-10-26", "Modification_Comment": "updated Observed_Examples"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-09-09", "Modification_Version": "4.18", "Modification_ReleaseDate": "2025-09-09", "Modification_Comment": "updated Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-12-11", "Modification_Version": "4.19", "Modification_ReleaseDate": "2025-12-11", "Modification_Comment": "updated Demonstrative_Examples"}], "Contribution": {"@Type": "Content", "Contribution_Name": "Parbati K. Manna", "Contribution_Organization": "Intel Corporation", "Contribution_Date": "2021-10-18", "Contribution_Comment": "provided detection methods"}, "Previous_Entry_Name": [{"@Date": "2020-08-20", "#text": "Missing Protection Against Voltage and Clock Glitches"}, {"@Date": "2021-10-28", "#text": "Missing or Improperly Implemented Protection Against Voltage and Clock Glitches"}]}}