CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (4.0)  
ID

CWE-1247: Missing Protection Against Voltage and Clock Glitches

Weakness ID: 1247
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product does not contain the necessary additional circuitry or sensors to detect and mitigate voltage and clock glitches.
+ Extended Description

A product might support security features such as secure boot that are supported through hardware and firmware implementation. 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, any password-checking logic for exercising the debug interface, etc. can implemented in hardware, firmware, or both. This implementation needs to be robust against fault attacks such as voltage glitches and clock glitches that an attacker may leverage to compromise the system.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.703Improper Check or Handling of Exceptional Conditions
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1206Power, Clock, and Reset Concerns
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Operation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

Power Management IP (Undetermined Prevalence)

Clock/Counter IP (Undetermined Prevalence)

Sensor IP (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism; Read Memory; Modify Memory; Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

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 the golden value. If the signatures match, the bootloader loads runtime firmware. If not, it is not loaded. If the underlying hardware executing this code does not contain any circuitry or sensors to detect voltage/clock glitches, an attacker might launch a fault-injection attack right when the signature check is happening (at the location marked with the comment), and it could bypass the signature-checking process.

(bad code)
Example Language: Other 
...

if (signature_matches) { // <-Glitch Here
load_runtime_firmware();
}
else {
do_not_load_runtime_firmware();
}

...

After bypassing secure boot, an attacker can gain access to system assets to which the attacker should not have access.

(informative)
 
If the underlying hardware detects a voltage/clock glitch, the information can be used to prevent the glitch from being successful.
+ Observed Examples
ReferenceDescription
Lack of anti-glitch protections allows an attacker to launch physical attack to bypass secure boot and read protected eFuses.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

At the circuit-level, using Tunable Replica Circuits (TRCs) or special flip-flops such as Razor flip-flops helps mitigate glitches. At SoC or platform level, level sensors can be implemented to detect glitches. Implementing redundancy in security-sensitive code (e.g., where checks are performed) helps in mitigating glitches.

+ References
[REF-1061] Keith Bowman, James Tschanz, Chris Wilkerson, Shih-Lien Lu, Tanay Karnik, Vivek De and Shekhar Borkar. "Circuit Techniques for Dynamic Variation Tolerance". <https://dl.acm.org/doi/10.1145/1629911.1629915>.
[REF-1062] Dan Ernst, Nam Sung Kim, Shidhartha Das, Sanjay Pant, Rajeev Rao, Toan Pham, Conrad Ziesler, David Blaauw, Todd Austin, Krisztian Flautner and Trevor Mudge. "Razor: A Low-Power Pipeline Based on Circuit-Level Timing Speculation". <https://web.eecs.umich.edu/~taustin/papers/MICRO36-Razor.pdf>.
[REF-1063] James Tschanz, Keith Bowman, Steve Walstra, Marty Agostinelli, Tanay Karnik and Vivek De. "Tunable Replica Circuits and Adaptive Voltage-Frequency Techniques for Dynamic Voltage, Temperature, and Aging Variation Tolerance". <https://ieeexplore.ieee.org/document/5205410>.
[REF-1064] Bilgiday Yuce, Nahid F. Ghalaty, Chinmay Deshpande, Conor Patrick, Leyla Nazhandali and Patrick Schaumont. "FAME: Fault-attack Aware Microprocessor Extensions for Hardware Fault Detection and Software Fault Response". <https://dl.acm.org/doi/10.1145/2948618.2948626>.
[REF-1065] Keith A. Bowman, James W. Tschanz, Shih-Lien L. Lu, Paolo A. Aseron, Muhammad M. Khellah, Arijit Raychowdhury, Bibiche M. Geuskens, Carlos Tokunaga, Chris B. Wilkerson, Tanay Karnik and Vivek De. "A 45 nm Resilient Microprocessor Core for Dynamic Variation Tolerance". <https://ieeexplore.ieee.org/document/5654663>.
[REF-1066] Niek Timmers and Albert Spruyt. "Bypassing Secure Boot Using Fault Injection". <https://www.blackhat.com/docs/eu-16/materials/eu-16-Timmers-Bypassing-Secure-Boot-Using-Fault-Injection.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2020-02-12Arun KanuparthiIntel Corporation
More information is available — Please select a different filter.
Page Last Updated: February 19, 2020