CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.3)  
ID

CWE-1332: Insufficient Protection Against Instruction Skipping Via Fault Injection

Weakness ID: 1332
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The device is missing or incorrectly implements circuitry or sensors to detect and mitigate CPU instruction skips that can be caused by fault injection.
+ Extended Description

Fault Injection is a technique used by adversaries to alter the operating conditions of hardware so that unexpected behavior occurs. Generally, this is accomplished by causing the device to operate outside of its expected conditions or by inducing electrical disturbances in the device. A weakness may arise in systems that do not properly protect against common fault injection techniques targeting the skipping of security critical instructions.

In practice, application code may contain conditional branches that are security-sensitive (e.g., accepting or rejecting a user-provided password. These conditional branches are typically implemented by a single conditional branch instruction in the program binary which, if skipped through fault injection, may lead to flipping the branch condition - i.e., causing the wrong security-sensitive branch to be taken. This affects processes such as firmware authentication, password verification, and other security-sensitive decision points.

+ 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.693Protection Mechanism Failure
+ 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
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1247Missing or Improperly Implemented Protection Against Voltage and Clock Glitches
+ 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
Architecture and DesignFailure to design appropriate countermeasures to common fault injection techniques can manifest this weakness.
ImplementationThis weakness can arise if the hardware design incorrectly implements countermeasures to prevent fault injection.
+ 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)

+ 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
Authentication

Technical Impact: Bypass Protection Mechanism; Alter Execution Logic; Unexpected State

Depending on the context, instruction skipping can have a broad range of consequences related to the generic bypassing of security critical code.
High
+ Potential Mitigations

Phase: Architecture and Design

Design strategies for ensuring safe failure if inputs such as Vcc are modified out of acceptable ranges

Phase: Architecture and Design

Design strategies for ensuring safe behaviour if instructions attempt to be skipped

Phase: Implementation

Ensure that architected fault mitigations are strong enough in practice. For example, a low power detection mechanism which takes 50 clock cycles to trigger at lower voltages may be an insufficient security mechanism if the instruction counter has already progressed with no other CPU activity occurring.
+ Notes

Maintenance

This entry is attack-oriented and may require significant modification in future versions, or even deprecation. It seems likely that there is more than one design "mistake" that might allow insruction skipping, so this entry is not necessarily a weakness and may be more appropriate for CAPEC.

Maintenance

This weakness has external references that are valuable but need to be further validated before addition to the weakness entry.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-10-14Jasper van WoudenbergRiscure
More information is available — Please select a different filter.
Page Last Updated: December 10, 2020