CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1194: Hardware Design (4.8)  
ID

CWE VIEW: Hardware Design

View ID: 1194
Type: Graph
Downloads: Booklet | CSV | XML
+ Objective
This view organizes weaknesses around concepts that are frequently used or encountered in hardware design. Accordingly, this view can align closely with the perspectives of designers, manufacturers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.
+ Audience
StakeholderDescription
Hardware DesignersHardware Designers use this view to better understand potential mistakes that can be made in specific areas of their IP design. The use of concepts with which hardware designers are familiar makes it easier to navigate.
EducatorsEducators use this view to teach future professionals about the types of mistakes that are commonly made in hardware design.
+ Relationships
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
1194 - Hardware Design
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Manufacturing and Life Cycle Management Concerns - (1195)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns)
Weaknesses in this category are root-caused to defects that arise in the semiconductor-manufacturing process or during the life cycle and supply chain.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insufficient Technical Documentation - (1059)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1059 (Insufficient Technical Documentation)
The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.
*BaseBase - 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.Semiconductor Defects in Hardware Logic with Security-Sensitive Implications - (1248)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)
The security-sensitive hardware module contains semiconductor defects.
*BaseBase - 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.Improper Scrubbing of Sensitive Data from Decommissioned Device - (1266)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1266 (Improper Scrubbing of Sensitive Data from Decommissioned Device)
The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned. A scrubbing capability could be missing, insufficient, or incorrect.
*BaseBase - 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.Product Released in Non-Release Configuration - (1269)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1269 (Product Released in Non-Release Configuration)
The product released to market is released in pre-production or manufacturing configuration.
*BaseBase - 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.Device Unlock Credential Sharing - (1273)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1273 (Device Unlock Credential Sharing)
The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.
*BaseBase - 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.Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
*BaseBase - 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.Unprotected Confidential Information on Device is Accessible by OSAT Vendors - (1297)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1297 (Unprotected Confidential Information on Device is Accessible by OSAT Vendors)
The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Security Flow Issues - (1196)
1194 (Hardware Design) > 1196 (Security Flow Issues)
Weaknesses in this category are related to improper design of full-system security flows, including but not limited to secure boot, secure update, and hardware-device attestation.
*BaseBase - 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.DMA Device Enabled Too Early in Boot Phase - (1190)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1190 (DMA Device Enabled Too Early in Boot Phase)
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.
*BaseBase - 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.Power-On of Untrusted Execution Core Before Enabling Fabric Access Control - (1193)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1193 (Power-On of Untrusted Execution Core Before Enabling Fabric Access Control)
The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.
*BaseBase - 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.Hardware Logic with Insecure De-Synchronization between Control and Data Channels - (1264)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1264 (Hardware Logic with Insecure De-Synchronization between Control and Data Channels)
The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.
*BaseBase - 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.Improper Access Control for Volatile Memory Containing Boot Code - (1274)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1274 (Improper Access Control for Volatile Memory Containing Boot Code)
The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.
*BaseBase - 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.Mutable Attestation or Measurement Reporting Data - (1283)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1283 (Mutable Attestation or Measurement Reporting Data)
The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.
*BaseBase - 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.Missing Ability to Patch ROM Code - (1310)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1310 (Missing Ability to Patch ROM Code)
Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.
*BaseBase - 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.Missing Immutable Root of Trust in Hardware - (1326)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1326 (Missing Immutable Root of Trust in Hardware)
A missing immutable root of trust in the hardware results in the ability to bypass secure boot or execute untrusted or adversarial boot code.
*BaseBase - 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.Security Version Number Mutable to Older Versions - (1328)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1328 (Security Version Number Mutable to Older Versions)
Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Integration Issues - (1197)
1194 (Hardware Design) > 1197 (Integration Issues)
Weaknesses in this category are those that arise due to integration of multiple hardware Intellectual Property (IP) cores, from System-on-a-Chip (SoC) subsystem interactions, or from hardware platform subsystem interactions.
*BaseBase - 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.Hardware Child Block Incorrectly Connected to Parent System - (1276)
1194 (Hardware Design) > 1197 (Integration Issues) > 1276 (Hardware Child Block Incorrectly Connected to Parent System)
Signals between a hardware IP and the parent system design are incorrectly connected causing security risks.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Privilege Separation and Access Control Issues - (1198)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues)
Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses.
*BaseBase - 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.Incorrect Default Permissions - (276)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 276 (Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Unintended Proxy or Intermediary ('Confused Deputy') - (441)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
*BaseBase - 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.Improper Isolation of Shared Resources on System-on-a-Chip (SoC) - (1189)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1189 (Improper Isolation of Shared Resources on System-on-a-Chip (SoC))
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
*BaseBase - 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.System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers - (1192)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1192 (System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers)
The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.
*BaseBase - 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.Insufficient Granularity of Access Control - (1220)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1220 (Insufficient Granularity of Access Control)
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
*BaseBase - 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.Inclusion of Undocumented Features or Chicken Bits - (1242)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1242 (Inclusion of Undocumented Features or Chicken Bits)
The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.
*BaseBase - 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.Improper Handling of Overlap Between Protected Memory Ranges - (1260)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1260 (Improper Handling of Overlap Between Protected Memory Ranges)
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
*BaseBase - 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.Improper Access Control for Register Interface - (1262)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1262 (Improper Access Control for Register Interface)
The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
*BaseBase - 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.Policy Uses Obsolete Encoding - (1267)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1267 (Policy Uses Obsolete Encoding)
The product uses an obsolete encoding mechanism to implement access controls.
*BaseBase - 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.Policy Privileges are not Assigned Consistently Between Control and Data Agents - (1268)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1268 (Policy Privileges are not Assigned Consistently Between Control and Data Agents)
The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
*BaseBase - 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.Access Control Check Implemented After Asset is Accessed - (1280)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1280 (Access Control Check Implemented After Asset is Accessed)
A product's hardware-based access control check occurs after the asset has been accessed.
+ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insecure Security Identifier Mechanism - (1294)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1294 (Insecure Security Identifier Mechanism)
The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.
*BaseBase - 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.Improper Restriction of Security Token Assignment - (1259)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1294 (Insecure Security Identifier Mechanism) > 1259 (Improper Restriction of Security Token Assignment)
The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.
*BaseBase - 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.Generation of Incorrect Security Tokens - (1270)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1294 (Insecure Security Identifier Mechanism) > 1270 (Generation of Incorrect Security Tokens)
The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.
*BaseBase - 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.Incorrect Decoding of Security Identifiers - (1290)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1294 (Insecure Security Identifier Mechanism) > 1290 (Incorrect Decoding of Security Identifiers )
The product implements a decoding mechanism to decode certain bus-transaction signals to security identifiers. If the decoding is implemented incorrectly, then untrusted agents can now gain unauthorized access to the asset.
*BaseBase - 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.Incorrect Conversion of Security Identifiers - (1292)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1294 (Insecure Security Identifier Mechanism) > 1292 (Incorrect Conversion of Security Identifiers)
The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers. However, if the conversion is incorrectly implemented, untrusted agents can gain unauthorized access to the asset.
*BaseBase - 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.Missing Protection Mechanism for Alternate Hardware Interface - (1299)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1299 (Missing Protection Mechanism for Alternate Hardware Interface)
The lack of protections on alternate paths to access control-protected assets (such as unprotected shadow registers and other external facing unguarded interfaces) allows an attacker to bypass existing protections to the asset that are only performed against the primary path.
*BaseBase - 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.Missing Security Identifier - (1302)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1302 (Missing Security Identifier)
The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier.
*BaseBase - 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.Non-Transparent Sharing of Microarchitectural Resources - (1303)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1303 (Non-Transparent Sharing of Microarchitectural Resources)
Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.
*BaseBase - 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.Missing Write Protection for Parametric Data Values - (1314)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1314 (Missing Write Protection for Parametric Data Values)
The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.
*BaseBase - 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.Missing Support for Security Features in On-chip Fabrics or Buses - (1318)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1318 (Missing Support for Security Features in On-chip Fabrics or Buses)
On-chip fabrics or buses either do not support or are not configured to support privilege separation or other security features, such as access control.
*BaseBase - 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.Unauthorized Error Injection Can Degrade Hardware Redundancy - (1334)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1334 (Unauthorized Error Injection Can Degrade Hardware Redundancy)
An unauthorized agent can inject errors into a redundant block to deprive the system of redundancy or put the system in a degraded operating mode.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.General Circuit and Logic Design Concerns - (1199)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns)
Weaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL.
*BaseBase - 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.Failure to Disable Reserved Bits - (1209)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1209 (Failure to Disable Reserved Bits)
The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.
*BaseBase - 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.Incorrect Register Defaults or Module Parameters - (1221)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1221 (Incorrect Register Defaults or Module Parameters)
Hardware description language code incorrectly defines register defaults or hardware IP parameters to insecure values.
*BaseBase - 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.Race Condition for Write-Once Attributes - (1223)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1223 (Race Condition for Write-Once Attributes)
A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.
*BaseBase - 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.Improper Restriction of Write-Once Bit Fields - (1224)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1224 (Improper Restriction of Write-Once Bit Fields)
The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.
*BaseBase - 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.Improper Prevention of Lock Bit Modification - (1231)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1231 (Improper Prevention of Lock Bit Modification)
The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.
*BaseBase - 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.Improper Lock Behavior After Power State Transition - (1232)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1232 (Improper Lock Behavior After Power State Transition)
Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.
*BaseBase - 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.Security-Sensitive Hardware Controls with Missing Lock Bit Protection - (1233)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1233 (Security-Sensitive Hardware Controls with Missing Lock Bit Protection)
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.
*BaseBase - 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.Hardware Internal or Debug Modes Allow Override of Locks - (1234)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)
System configuration protection may be bypassed during debug mode.
*BaseBase - 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.Improper Finite State Machines (FSMs) in Hardware Logic - (1245)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1245 (Improper Finite State Machines (FSMs) in Hardware Logic)
Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.
*BaseBase - 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.Incorrect Selection of Fuse Values - (1253)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1253 (Incorrect Selection of Fuse Values)
The logic level used to set a system to a secure state relies on a fuse being unblown. An attacker can set the system to an insecure state merely by blowing the fuse.
*BaseBase - 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.Incorrect Comparison Logic Granularity - (1254)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1254 (Incorrect Comparison Logic Granularity)
The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.
*BaseBase - 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.Improper Handling of Single Event Upsets - (1261)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1261 (Improper Handling of Single Event Upsets)
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
*BaseBase - 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.Hardware Logic Contains Race Conditions - (1298)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1298 (Hardware Logic Contains Race Conditions)
A race condition in the hardware logic results in undermining security guarantees of the system.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Core and Compute Issues - (1201)
1194 (Hardware Design) > 1201 (Core and Compute Issues)
Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.
*BaseBase - 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.CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations - (1252)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1252 (CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations)
The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.
*BaseBase - 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.Sequence of Processor Instructions Leads to Unexpected Behavior - (1281)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1281 (Sequence of Processor Instructions Leads to Unexpected Behavior)
Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed.
*BaseBase - 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.Information Exposure through Microarchitectural State after Transient Execution - (1342)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1342 (Information Exposure through Microarchitectural State after Transient Execution)
The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Memory and Storage Issues - (1202)
1194 (Hardware Design) > 1202 (Memory and Storage Issues)
Weaknesses in this category are typically associated with memory (e.g., DRAM, SRAM) and storage technologies (e.g., NAND Flash, OTP, EEPROM, and eMMC).
+BaseBase - 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.Sensitive Information in Resource Not Removed Before Reuse - (226)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 226 (Sensitive Information in Resource Not Removed Before Reuse)
The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
*VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Improper Zeroization of Hardware Register - (1239)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 226 (Sensitive Information in Resource Not Removed Before Reuse) > 1239 (Improper Zeroization of Hardware Register)
The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.
*BaseBase - 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.Information Exposure through Microarchitectural State after Transient Execution - (1342)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 226 (Sensitive Information in Resource Not Removed Before Reuse) > 1342 (Information Exposure through Microarchitectural State after Transient Execution)
The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.
*BaseBase - 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.Improper Write Handling in Limited-write Non-Volatile Memories - (1246)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1246 (Improper Write Handling in Limited-write Non-Volatile Memories)
The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.
*BaseBase - 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.Mirrored Regions with Different Values - (1251)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1251 (Mirrored Regions with Different Values)
The product's architecture mirrors regions without ensuring that their contents always stay in sync.
*BaseBase - 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.Improper Access Control Applied to Mirrored or Aliased Memory Regions - (1257)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1257 (Improper Access Control Applied to Mirrored or Aliased Memory Regions)
Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.
*BaseBase - 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.Assumed-Immutable Data is Stored in Writable Memory - (1282)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1282 (Assumed-Immutable Data is Stored in Writable Memory)
Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Peripherals, On-chip Fabric, and Interface/IO Problems - (1203)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems)
Weaknesses in this category are related to hardware security problems that apply to peripheral devices, IO interfaces, on-chip interconnects, network-on-chip (NoC), and buses. For example, this category includes issues related to design of hardware interconnect and/or protocols such as PCIe, USB, SMBUS, general-purpose IO pins, and user-input peripherals such as mouse and keyboard.
*BaseBase - 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.Improper Translation of Security Attributes by Fabric Bridge - (1311)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1311 (Improper Translation of Security Attributes by Fabric Bridge)
The bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.
*BaseBase - 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.Missing Protection for Mirrored Regions in On-Chip Fabric Firewall - (1312)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1312 (Missing Protection for Mirrored Regions in On-Chip Fabric Firewall)
The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.
*BaseBase - 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.Improper Setting of Bus Controlling Capability in Fabric End-point - (1315)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1315 (Improper Setting of Bus Controlling Capability in Fabric End-point)
The bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric.
*BaseBase - 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.Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges - (1316)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1316 (Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges)
The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.
*BaseBase - 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.Missing Security Checks in Fabric Bridge - (1317)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1317 (Missing Security Checks in Fabric Bridge)
A bridge that is connected to a fabric without security features forwards transactions to the slave without checking the privilege level of the master. Similarly, it does not check the hardware identity of the transaction received from the slave interface of the bridge.
*BaseBase - 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.Improper Protection against Electromagnetic Fault Injection (EM-FI) - (1319)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1319 (Improper Protection against Electromagnetic Fault Injection (EM-FI))
The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.
*BaseBase - 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.Improper Isolation of Shared Resources in Network On Chip (NoC) - (1331)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1331 (Improper Isolation of Shared Resources in Network On Chip (NoC))
The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Security Primitives and Cryptography Issues - (1205)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues)
Weaknesses in this category are related to hardware implementations of cryptographic protocols and other hardware-security primitives such as physical unclonable functions (PUFs) and random number generators (RNGs).
+BaseBase - 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.Observable Discrepancy - (203)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 203 (Observable Discrepancy)
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.Side Channel Attack
*BaseBase - 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.Improper Protection of Physical Side Channels - (1300)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 203 (Observable Discrepancy) > 1300 (Improper Protection of Physical Side Channels)
The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.
*BaseBase - 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.Missing Cryptographic Step - (325)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 325 (Missing Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
*BaseBase - 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.Use of a Cryptographic Primitive with a Risky Implementation - (1240)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1240 (Use of a Cryptographic Primitive with a Risky Implementation)
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.
*BaseBase - 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.Use of Predictable Algorithm in Random Number Generator - (1241)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1241 (Use of Predictable Algorithm in Random Number Generator)
The device uses an algorithm that is predictable and generates a pseudo-random number.
*BaseBase - 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.Cryptographic Operations are run Before Supporting Units are Ready - (1279)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1279 (Cryptographic Operations are run Before Supporting Units are Ready)
Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.
*BaseBase - 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.Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)
A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Power, Clock, and Reset Concerns - (1206)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns)
Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level.
*BaseBase - 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.Improper Lock Behavior After Power State Transition - (1232)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1232 (Improper Lock Behavior After Power State Transition)
Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.
*BaseBase - 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.Improper Protection Against Voltage and Clock Glitches - (1247)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1247 (Improper Protection Against Voltage and Clock Glitches)
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.
*VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Comparison Logic is Vulnerable to Power Side-Channel Attacks - (1255)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1255 (Comparison Logic is Vulnerable to Power Side-Channel Attacks)
A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.
*BaseBase - 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.Improper Restriction of Software Interfaces to Hardware Features - (1256)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1256 (Improper Restriction of Software Interfaces to Hardware Features)
The product provides software-controllable device functionality for capabilities such as power and clock management, but it does not properly limit functionality that can lead to modification of hardware memory or register bits, or the ability to observe physical side channels.
*BaseBase - 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.Uninitialized Value on Reset for Registers Holding Security Settings - (1271)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1271 (Uninitialized Value on Reset for Registers Holding Security Settings)
Security-critical logic is not set to a known value on reset.
*BaseBase - 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.Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation - (1304)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1304 (Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation)
The product performs a power save/restore operation, but it does not ensure that the integrity of the configuration state is maintained and/or verified between the beginning and ending of the operation.
*BaseBase - 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.Missing Write Protection for Parametric Data Values - (1314)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1314 (Missing Write Protection for Parametric Data Values)
The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.
*BaseBase - 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.Improper Protection for Out of Bounds Signal Level Alerts - (1320)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1320 (Improper Protection for Out of Bounds Signal Level Alerts)
Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.
*BaseBase - 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.Improper Handling of Faults that Lead to Instruction Skips - (1332)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1332 (Improper Handling of Faults that Lead to Instruction Skips)
The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.
*BaseBase - 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.Improper Protections Against Hardware Overheating - (1338)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1338 (Improper Protections Against Hardware Overheating)
A hardware device is missing or has inadequate protection features to prevent overheating.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Debug and Test Problems - (1207)
1194 (Hardware Design) > 1207 (Debug and Test Problems)
Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.
*BaseBase - 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.On-Chip Debug and Test Interface With Improper Access Control - (1191)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1191 (On-Chip Debug and Test Interface With Improper Access Control)
The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.
*BaseBase - 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.Hardware Internal or Debug Modes Allow Override of Locks - (1234)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)
System configuration protection may be bypassed during debug mode.
*BaseBase - 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.Sensitive Non-Volatile Information Not Protected During Debug - (1243)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1243 (Sensitive Non-Volatile Information Not Protected During Debug)
Access to security-sensitive information stored in fuses is not limited during debug.
*BaseBase - 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.Internal Asset Exposed to Unsafe Debug Access Level or State - (1244)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1244 (Internal Asset Exposed to Unsafe Debug Access Level or State)
The product uses physical debug or test interfaces with support for multiple access levels, but it assigns the wrong debug access level to an internal asset, providing unintended access to the asset from untrusted debug agents.
*BaseBase - 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.Exposure of Sensitive System Information Due to Uncleared Debug Information - (1258)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1258 (Exposure of Sensitive System Information Due to Uncleared Debug Information)
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
*BaseBase - 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.Sensitive Information Uncleared Before Debug/Power State Transition - (1272)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1272 (Sensitive Information Uncleared Before Debug/Power State Transition)
The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.
*BaseBase - 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.Public Key Re-Use for Signing both Debug and Production Code - (1291)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1291 (Public Key Re-Use for Signing both Debug and Production Code)
The same public key is used for signing both debug and production code.
*BaseBase - 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.Debug Messages Revealing Unnecessary Information - (1295)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1295 (Debug Messages Revealing Unnecessary Information)
The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.
*BaseBase - 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.Incorrect Chaining or Granularity of Debug Components - (1296)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1296 (Incorrect Chaining or Granularity of Debug Components)
The product's debug components contain incorrect chaining or granularity of debug components.
*BaseBase - 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.Hardware Allows Activation of Test or Debug Logic at Runtime - (1313)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1313 (Hardware Allows Activation of Test or Debug Logic at Runtime)
During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.
*BaseBase - 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.Improper Management of Sensitive Trace Data - (1323)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1323 (Improper Management of Sensitive Trace Data)
Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.
*BaseBase - 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.Sensitive Information Accessible by Physical Probing of JTAG Interface - (1324)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1324 (Sensitive Information Accessible by Physical Probing of JTAG Interface)
Sensitive information in clear text on the JTAG interface may be examined by an eavesdropper, e.g. by placing a probe device on the interface such as a logic analyzer, or a corresponding software technique.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Cross-Cutting Problems - (1208)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems)
Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.
*BaseBase - 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.Expected Behavior Violation - (440)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 440 (Expected Behavior Violation)
A feature, API, or function does not perform according to its specification.
*BaseBase - 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.Missing Documentation for Design - (1053)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1053 (Missing Documentation for Design)
The product does not have documentation that represents how it is designed.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insufficient Technical Documentation - (1059)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1059 (Insufficient Technical Documentation)
The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Physical Access Control - (1263)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1263 (Improper Physical Access Control)
The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.
*BaseBase - 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.Firmware Not Updateable - (1277)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1277 (Firmware Not Updateable)
The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.
*BaseBase - 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.Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
*BaseBase - 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.Improper Protection of Physical Side Channels - (1300)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1300 (Improper Protection of Physical Side Channels)
The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.
+BaseBase - 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.Insufficient or Incomplete Data Removal within Hardware Component - (1301)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1301 (Insufficient or Incomplete Data Removal within Hardware Component)
The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.
*VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Remanent Data Readable after Memory Erase - (1330)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1301 (Insufficient or Incomplete Data Removal within Hardware Component) > 1330 (Remanent Data Readable after Memory Erase)
Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Physical Access Issues and Concerns - (1388)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns)
Weaknesses in this category are related to concerns of physical access.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Handling of Physical or Environmental Conditions - (1384)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1384 (Improper Handling of Physical or Environmental Conditions)
The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.
*BaseBase - 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.Improper Protection against Electromagnetic Fault Injection (EM-FI) - (1319)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1319 (Improper Protection against Electromagnetic Fault Injection (EM-FI))
The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.
*BaseBase - 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.Improper Protection Against Voltage and Clock Glitches - (1247)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1247 (Improper Protection Against Voltage and Clock Glitches)
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.
*BaseBase - 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.Improper Handling of Single Event Upsets - (1261)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1261 (Improper Handling of Single Event Upsets)
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
*BaseBase - 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.Improper Handling of Faults that Lead to Instruction Skips - (1332)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1332 (Improper Handling of Faults that Lead to Instruction Skips)
The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.
*BaseBase - 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.Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)
A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures.
*BaseBase - 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.Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
*VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Comparison Logic is Vulnerable to Power Side-Channel Attacks - (1255)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1255 (Comparison Logic is Vulnerable to Power Side-Channel Attacks)
A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.
*BaseBase - 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.Improper Protection of Physical Side Channels - (1300)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1300 (Improper Protection of Physical Side Channels)
The device does not contain sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to patterns in physically observable phenomena such as variations in power consumption, electromagnetic emissions (EME), or acoustic emissions.
*BaseBase - 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.Semiconductor Defects in Hardware Logic with Security-Sensitive Implications - (1248)
1194 (Hardware Design) > 1388 (Physical Access Issues and Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)
The security-sensitive hardware module contains semiconductor defects.
+ Notes

Other

The top level categories in this view represent commonly understood areas/terms within hardware design, and are meant to aid the user in identifying potential related weaknesses. It is possible for the same weakness to exist within multiple different categories.

Other

This view attempts to present weaknesses in a simple and intuitive way. As such it targets a single level of abstraction. It is important to realize that not every CWE will be represented in this view. High-level class weaknesses and low-level variant weaknesses are mostly ignored. However, by exploring the weaknesses that are included, and following the defined relationships, one can find these higher and lower level weaknesses.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses100out of 927
Categories13out of 352
Views0out of 48
Total113out of1327
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2022-06-28CWE Content TeamMITRE
updated Relationships

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-1280: Access Control Check Implemented After Asset is Accessed

Weakness ID: 1280
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
A product's hardware-based access control check occurs after the asset has been accessed.
+ Extended Description

The product implements a hardware-based access control check. The asset should be accessible only after the check is successful. If, however, this operation is not atomic and the asset is accessed before the check is complete, the security of the system may be compromised.

+ Relationships
Section HelpThis table 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.284Improper Access Control
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.696Incorrect Behavior Order
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction
Section HelpThe 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
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control
Confidentiality
Integrity

Technical Impact: Modify Memory; Read Memory; Modify Application Data; Read Application Data; Gain Privileges or Assume Identity; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.

(bad code)
Example Language: Verilog 
module foo_bar(data_out, usr_id, data_in, clk, rst_n);

output reg [7:0] data_out;

input wire [2:0] usr_id;

input wire [7:0] data_in;

input wire clk, rst_n;

wire grant_access;

always @ (posedge clk or negedge rst_n)

begin

if (!rst_n)
data_out = 0;
else
data_out = (grant_access) ? data_in : data_out;
assign grant_access = (usr_id == 3’h4) ? 1’b1 : 1’b0;
end
endmodule

This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1.

(good code)
Example Language: Verilog 

Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below.

always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
data_out = 0;
else
assign grant_access = (usr_id == 3’h4) ? 1’b1 : 1’b0;
data_out = (grant_access) ? data_in : data_out;
end
endmodule
+ Potential Mitigations

Phase: Implementation

Implement the access control check first. Access should only be given to asset if agent is authorized.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Related_Attack_Patterns

CWE-1282: Assumed-Immutable Data is Stored in Writable Memory

Weakness ID: 1282
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.
+ Extended Description

Security services such as secure boot, authentication of code and data, and device attestation all require assets such as the first stage bootloader, public keys, golden hash digests, etc. which are implicitly trusted. Storing these assets in read-only memory (ROM), fuses, or one-time programmable (OTP) memory provides strong integrity guarantees and provides a root of trust for securing the rest of the system. Security is lost if assets assumed to be immutable can be modified.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.668Exposure of Resource to Wrong Sphere
CanPrecedeBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Modes Of Introduction
Section HelpThe 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
ImplementationKeys, code, configuration settings, and other data should be programmed in write-once or read-only memory instead of writable memory.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Integrity

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Cryptographic hash functions are commonly used to create unique fixed-length digests used to ensure the integrity of code and keys. A golden digest is stored on the device and compared to the digest computed from the data to be verified. If the digests match, the data has not been maliciously modified. If an attacker can modify the golden digest they then have the ability to store arbitrary data that passes the verification check. Hash digests used to verify public keys and early stage boot code should be immutable, with the strongest protection offered by hardware immutability.

+ Potential Mitigations

Phase: Implementation

All immutable code or data should be programmed into ROM or write-once memory.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.

Maintenance

As of CWE 4.3, CWE-1282 and CWE-1233 are being investigated for potential duplication or overlap.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-15Nicole FernTortuga Logic
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Name
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Assumed-Immutable Data Stored in Writable Memory

CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks

Weakness ID: 1255
Abstraction: Variant
Structure: Simple
Presentation Filter:
+ Description
A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.
+ Extended Description

The power consumed by a device may be instrumented and monitored in real time. If the algorithm for evaluating security tokens is not sufficiently robust, the power consumption may vary by token entry comparison against the reference value. Further, if retries are unlimited, the power difference between a "good" entry and a "bad" entry may be observed and used to determine whether each entry itself is correct thereby allowing unauthorized parties to calculate the reference value.

+ Relationships
Section HelpThis table 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
ChildOfBaseBase - 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.1300Improper Protection of Physical Side Channels
Section HelpThis table 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 "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
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1388Physical Access Issues and 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.1259Improper Restriction of Security Token Assignment
+ Modes Of Introduction
Section HelpThe 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 DesignThe design of the algorithm itself may intrinsically allow the power side channel attack to be effective
ImplementationThis weakness may be introduced during implementation despite a robust design that otherwise prevents exploitation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Modify Memory; Read Memory; Read Files or Directories; Modify Files or Directories; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Read Application Data; Modify Application Data; Hide Activities

As compromising a security token may result in complete system control, the impacts are relatively universal
+ Demonstrative Examples

Example 1

Consider an example hardware module that checks a user-provided password (or PIN) to grant access to a user. The user-provided password is compared against a stored value byte-by-byte.

(bad code)
Example Language: Other 

static nonvolatile password_tries = NUM_RETRIES;
do
  while (password_tries == 0) ; // Hang here if no more password tries
  password_ok = 0;
  for (i = 0; i < NUM_PW_DIGITS; i++)
    if (GetPasswordByte() == stored_password([i])
      password_ok |= 1; // Power consumption is different here
    else
      password_ok |= 0; // than from here
  end
  if (password_ok > 0)
    password_tries = NUM_RETRIES;
    break_to_Ok_to_proceed
  password_tries--;
while (true)
// Password OK

Since the algorithm uses a different number of 1's and 0's for password validation, a different amount of power is consumed for the good byte versus the bad byte comparison. Using this information, an attacker may be able to guess the correct password for that byte-by-byte iteration with several repeated attempts by stopping the password evaluation before it completes.

(good code)
 


Among various options for mitigating the string comparison is obscuring the power comsumption by having opposing bit flips during bit operations. Note that in this example, the initial change of the bit values could still provide power indication depending upon the hardware itself. This possibility needs to be measured for verification.
static nonvolatile password_tries = NUM_RETRIES;
do
  while (password_tries == 0) ; // Hang here if no more password tries
  password_tries--; // Put retry code here to catch partial retries
  password_ok = 0;
  for (i = 0; i < NUM_PW_DIGITS; i++)
    if (GetPasswordByte() == stored_password([i])
      password_ok |= 0x10; // Power consumption here
    else
      password_ok |= 0x01; // is now the same here
  end
  if ((password_ok & 1) == 0)
    password_tries = NUM_RETRIES;
    break_to_Ok_to_proceed
while (true)
// Password OK

Since the algorithm uses a different number of 1's and 0's for password validation, a different amount of power is consumed for the good byte versus the bad byte comparison. Using this information, an attacker may be able to guess the correct password for that byte-by-byte iteration with several repeated attempts by stopping the password evaluation before it completes.

(good code)
 

An alternative to the previous example is simply comparing the whole password simultaneously.

static nonvolatile password_tries = NUM_RETRIES;
do
  while (password_tries == 0) ; // Hang here if no more password tries
  password_tries--; // Put retry code here to catch partial retries
  for (i = 0; i < NUM_PW_DIGITS; i++)
    stored_password([i] = GetPasswordByte();
  end
  if (stored_password == saved_password)
    password_tries = NUM_RETRIES;
    break_to_Ok_to_proceed
while (true)
// Password OK

Since comparison is done atomically, there is no indication which bytes fail forcing the attacker to brute force the whole password at once. Note that other mitigations may exist such as masking - causing a large current draw to mask individual bit flips.

Example 2

This code demonstrates the transfer of a secret key using Serial-In/Serial-Out shift. It's easy to extract the secret using simple power analysis as each shift gives data on a single bit of the key.

(bad code)
Example Language: Other 

module siso(clk,rst,a,q);
input a;
input clk,rst;
output q;
reg q;

always@(posedge clk,posedge rst)
begin
if(rst==1'b1)
q<1'b0;
else
q<a;
end
endmodule

This code demonstrates the transfer of a secret key using a Parallel-In/Parallel-Out shift. In a parallel shift, data confounded by multiple bits of the key, not just one.

(good code)
Example Language: Other 

module pipo(clk,rst,a,q);
input clk,rst;
input[3:0]a;
output[3:0]q;
reg[3:0]q;

always@(posedge clk,posedge rst)
begin
if (rst==1'b1)
q<4'b0000;
else
q<a;
end
endmodule
+ Observed Examples
ReferenceDescription
CMAC verification vulnerable to timing and power attacks.
+ Potential Mitigations

Phase: Architecture and Design

The design phase must consider each check of a security token against a standard and the amount of power consumed during the check of a good token versus a bad token. The alternative is an all at once check where a retry counter is incremented PRIOR to the check.

Phase: Architecture and Design

Another potential mitigation is to parallelize shifting of secret data (see example 2 below). Note that the wider the bus the more effective the result.

Phase: Architecture and Design

An additional potential mitigation is to add random data to each crypto operation then subtract it out afterwards. This is highly effective but costly in performance, area, and power consumption. It also requires a random number generator.

Phase: Implementation

If the architecture is unable to prevent the attack, using filtering components may reduce the ability to implement an attack, however, consideration must be given to the physical removal of the filter elements.

Phase: Integration

During integration, avoid use of a single secret for an extended period (e.g. frequent key updates). This limits the amount of data compromised but at the cost of complexity of use.
+ Functional Areas
  • Power
+ References
[REF-1184] Wikipedia. "Power Analysis". <https://en.wikipedia.org/wiki/Power_analysis>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-29CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2020-09-09Accellera IP Security Assurance (IPSA) Working GroupAccellera Systems Initiative
Submitted new material that could be added to already-existing entry CWE-1255. Added new Potential Mitigations, a new example, an observed example, and an additional reference.
+ Modifications
Modification DateModifierOrganization
2021-03-15CWE Content TeamMITRE
updated Functional_Areas, Maintenance_Notes, Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Maintenance_Notes, References, Relationships, Type
2022-06-28CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: Core and Compute Issues

Category ID: 1201
+ Summary
Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - 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.1252CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
HasMemberBaseBase - 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.1281Sequence of Processor Instructions Leads to Unexpected Behavior
HasMemberBaseBase - 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.1342Information Exposure through Microarchitectural State after Transient Execution
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships

CWE-1252: CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

Weakness ID: 1252
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.
+ Extended Description

CPUs provide a special bit that supports exclusivity of write and execute operations. This bit is used to segregate areas of memory to either mark them as code (instructions, which can be executed) or data (which should not be executed). In this way, if a user can write to a region of memory, the user cannot execute from that region and vice versa. This exclusivity provided by special hardware bit is leveraged by the operating system to protect executable space. While this bit is available in most modern processors by default, in some CPUs the exclusivity is implemented via a memory-protection unit (MPU) and memory-management unit (MMU) in which memory regions can be carved out with exact read, write, and execute permissions. However, if the CPU does not have an MMU/MPU, then there is no write exclusivity. Without configuring exclusivity of operations via segregated areas of memory, an attacker may be able to inject malicious code onto memory and later execute it.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1201Core and Compute Issues
+ Modes Of Introduction
Section HelpThe 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 Design
+ Applicable Platforms
Section HelpThis listing shows 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

Microcontroller Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

MCS51 Microcontroller (based on 8051) does not have a special bit to support write exclusivity. It also does not have an MMU/MPU support. The Cortex-M CPU has an optional MPU that supports up to 8 regions.

(bad code)
Example Language: Other 
The optional MPU is not configured.

If the MPU is not configured, then an attacker will be able to inject malicious data into memory and execute it.

+ Potential Mitigations

Phase: Architecture and Design

Implement a dedicated bit that can be leveraged by the Operating System to mark data areas as non-executable. If such a bit is not available in the CPU, implement MMU/MPU (memory management unit / memory protection unit).

Phase: Integration

If MMU/MPU are not available, then the firewalls need to be implemented in the SoC interconnect to mimic the write-exclusivity operation.

+ References
[REF-1077] Intel. "MCS 51 Microcontroller Family User's Manual". <http://web.mit.edu/6.115/www/document/8051.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-13Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms

CWE CATEGORY: Cross-Cutting Problems

Category ID: 1208
+ Summary
Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - 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.440Expected Behavior Violation
HasMemberBaseBase - 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.1053Missing Documentation for Design
HasMemberClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1059Insufficient Technical Documentation
HasMemberClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1263Improper Physical Access Control
HasMemberBaseBase - 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.1277Firmware Not Updateable
HasMemberBaseBase - 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.1278Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
HasMemberBaseBase - 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.1300Improper Protection of Physical Side Channels
HasMemberBaseBase - 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.1301Insufficient or Incomplete Data Removal within Hardware Component
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships

CWE-1279: Cryptographic Operations are run Before Supporting Units are Ready

Weakness ID: 1279
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.
+ Extended Description
Many cryptographic hardware units depend upon other hardware units to supply information to them to produce a securely encrypted result. For example, a cryptographic unit that depends on an external random-number-generator (RNG) unit for entropy must wait until the RNG unit is producing random numbers. If a cryptographic unit retrieves a private encryption key from a fuse unit, the fuse unit must be up and running before a key may be supplied.
+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.665Improper Initialization
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
+ Modes Of Introduction
Section HelpThe 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 Design
ImplementationThe decision to continue using a cryptographic unit even though the input units to it are not producing valid data will compromise the encrypted result.
+ Applicable Platforms
Section HelpThis listing shows 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

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Processor Hardware (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control
Confidentiality
Integrity
Availability
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

The following pseudocode illustrates the weak encryption resulting from the use of a pseudo-random-number generator output.

(bad code)
Example Language: Other 

If random_number_generator_self_test_passed() == TRUE

then Seed = get_random_number_from_RNG()

else Seed = hardcoded_number

In the example above, first a check of RNG ready is performed. If the check fails, the RNG is ignored and a hard coded value is used instead. The hard coded value severely weakens the encrypted output.

(good code)
Example Language: Other 

If random_number_generator_self_test_passed() == TRUE

then Seed = get_random_number_from_RNG()

else enter_error_state()

+ Potential Mitigations

Phase: Architecture and Design

Best practices should be used to design cryptographic systems.

Phase: Implementation

Continuously ensuring that cryptographic inputs are supplying valid information is necessary to ensure that the encrypted output is secure.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Cryptographic Primitives used without Successful Self-Test

CWE CATEGORY: Debug and Test Problems

Category ID: 1207
+ Summary
Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - 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.1191On-Chip Debug and Test Interface With Improper Access Control
HasMemberBaseBase - 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.1234Hardware Internal or Debug Modes Allow Override of Locks
HasMemberBaseBase - 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.1243Sensitive Non-Volatile Information Not Protected During Debug
HasMemberBaseBase - 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.1244Internal Asset Exposed to Unsafe Debug Access Level or State
HasMemberBaseBase - 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.1258Exposure of Sensitive System Information Due to Uncleared Debug Information
HasMemberBaseBase - 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.1272Sensitive Information Uncleared Before Debug/Power State Transition
HasMemberBaseBase - 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.1291Public Key Re-Use for Signing both Debug and Production Code
HasMemberBaseBase - 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.1295Debug Messages Revealing Unnecessary Information
HasMemberBaseBase - 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.1296Incorrect Chaining or Granularity of Debug Components
HasMemberBaseBase - 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.1313Hardware Allows Activation of Test or Debug Logic at Runtime
HasMemberBaseBase - 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.1323Improper Management of Sensitive Trace Data
HasMemberBaseBase - 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.1324Sensitive Information Accessible by Physical Probing of JTAG Interface
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships

CWE-1295: Debug Messages Revealing Unnecessary Information

Weakness ID: 1295
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.
+ Extended Description

Debug messages are messages that help troubleshoot an issue by revealing the internal state of the system. For example, debug data in design can be exposed through internal memory array dumps or boot logs through interfaces like UART via TAP commands, scan chain, etc. Thus, the more information contained in a debug message, the easier it is to debug. However, there is also the risk of revealing information that could help an attacker either decipher a vulnerability, and/or gain a better understanding of the system. Thus, this extra information could lower the “security by obscurity” factor. While “security by obscurity” alone is insufficient, it can help as a part of “Defense-in-depth”.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.200Exposure of Sensitive Information to an Unauthorized Actor
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.209Generation of Error Message Containing Sensitive Information
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction
Section HelpThe 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
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Read Memory; Bypass Protection Mechanism; Gain Privileges or Assume Identity; Varies by Context

Medium
+ Demonstrative Examples

Example 1

This example here shows how an attacker can take advantage of unnecessary information in debug messages.

Example 1: Suppose in response to a Test Access Port (TAP) chaining request the debug message also reveals the current TAP hierarchy (the full topology) in addition to the success/failure message.

Example 2: In response to a password-filling request, the debug message, instead of a simple Granted/Denied response, prints an elaborate message, “The user-entered password does not match the actual password stored in <directory name>.”

The result of the above examples is that the user is able to gather additional unauthorized information about the system from the debug messages.

The solution is to ensure that Debug messages do not reveal additional details.

+ Observed Examples
ReferenceDescription
modem debug messages include cryptographic keys
+ Potential Mitigations

Phase: Implementation

Ensure that a debug message does not reveal any unnecessary information during the debug process for the intended response.
+ References
[REF-1112] "Android Security Bulletin—December 2018". <https://source.android.com/security/bulletin/2018-12-01.html>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-31Parbati Kumar Manna, Hareesh Khattri, Arun KanuparthiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2021-07-20CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships

CWE-1273: Device Unlock Credential Sharing

Weakness ID: 1273
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.
+ Extended Description

“Unlocking a device” often means activating certain, unadvertised, debug and manufacturer-specific capabilities of a device using sensitive credentials. Unlocking a device might be necessary for the purpose of troubleshooting device problems. For example, suppose a device contains the ability to dump the content of the full system memory by disabling the memory-protection mechanisms. Since this is a highly security-sensitive capability, this capability is “locked” in the production part. Unless the device gets unlocked by supplying the proper credentials the debug capabilities are not available. For cases where the chip designer, chip manufacturer (fabricator), and manufacturing and assembly testers are the all employed by the same company, the compromise of the credentials are greatly reduced. However, when the chip designer is employed by one company, the chip manufacturer is employed by another company (a foundry), and the assemblers and testers are employed by yet a third company. Since these different companies will need to perform various tests on the device to verify correct device function, they all need to share the unlock key. Unfortunately, the level of secrecy and policy might be quite different at each company, greatly increasing the risk of sensitive credentials being compromised.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1195Manufacturing and Life Cycle Management Concerns
+ Modes Of Introduction
Section HelpThe 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
Integration
Manufacturing
+ Applicable Platforms
Section HelpThis listing shows 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

VHDL (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

Class: Compiled (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Other (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Accountability
Authentication
Authorization
Non-Repudiation

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

Once unlock credentials are compromised, an attacker can use the credentials to unlock the device and gain unauthorized access to the hidden functionalities protected by those credentials.
+ Demonstrative Examples

Example 1

This example shows how an attacker can take advantage of compromised credentials.

(bad code)
 
Suppose a semiconductor chipmaker, “C”, uses the foundry “F” for fabricating its chips. Now, F has many other customers in addition to C, and some of the other customers are much smaller companies. F has dedicated teams for each of its customers, but somehow it mixes up the unlock credentials and sends the unlock credentials of C to the wrong team. This other team does not take adequate precautions to protect the credentials that have nothing to do with them, and eventually the unlock credentials of C get leaked.

When the credentials of multiple organizations are stored together, exposure to third parties occurs frequently.

(good code)
 
Vertical integration of a production company is one effective method of protecting sensitive credentials. Where vertical integration is not possible, strict access control and need-to-know are methods which can be implemented to reduce these risks.
+ Potential Mitigations

Phase: Integration

Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.

Phase: Manufacturing

Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-29Parbati Kumar Manna, Hareesh Khattri, Arun KanuparthiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description

CWE-1190: DMA Device Enabled Too Early in Boot Phase

Weakness ID: 1190
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.
+ Extended Description

DMA is included in a number of devices because it allows data transfer between the computer and the connected device, using direct hardware access to read or write directly to main memory without any OS interaction. An attacker could exploit this to access secrets. Several virtualization-based mitigations have been introduced to thwart DMA attacks. These are usually configured/setup during boot time. However, certain IPs that are powered up before boot is complete (known as early boot IPs) may be DMA capable. Such IPs, if not trusted, could launch DMA attacks and gain access to assets that should otherwise be protected.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.696Incorrect Behavior Order
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction
Section HelpThe 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 Design
+ Applicable Platforms
Section HelpThis listing shows 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)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Bypass Protection Mechanism; Modify Memory

DMA devices have direct write access to main memory and due to time of attack will be able to bypass OS or Bootloader access control.
High
+ Potential Mitigations

Phase: Architecture and Design

Utilize an IOMMU to orchestrate IO access from the start of the boot process.
+ References
[REF-1038] "DMA attack". 2019-10-19. <https://en.wikipedia.org/wiki/DMA_attack>.
[REF-1039] A. Theodore Markettos, Colin Rothwell, Brett F. Gutstein, Allison Pearce, Peter G. Neumann, Simon W. Moore and Robert N. M. Watson. "Thunderclap: Exploring Vulnerabilities in Operating System IOMMU Protection via DMA from Untrustworthy Peripherals". 2019-02-25. <https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_05A-1_Markettos_paper.pdf>.
[REF-1040] Maximillian Dornseif, Michael Becher and Christian N. Klein. "FireWire all your memory are belong to us". 2005. <https://cansecwest.com/core05/2005-firewire-cansecwest.pdf>.
[REF-1041] Rory Breuk, Albert Spruyt and Adam Boileau. "Integrating DMA attacks in exploitation frameworks". 2012-02-20. <https://www.os3.nl/_media/2011-2012/courses/rp1/p14_report.pdf>.
[REF-1042] Maximillian Dornseif. "Owned by an iPod". 2004. <https://pacsec.jp/psj04/psj04-dornseif-e.ppt>.
[REF-1044] Dmytro Oleksiuk. "My aimful life". 2015-09-12. <http://blog.cr4.sh/2015/09/breaking-uefi-security-with-software.html>.
[REF-1046] A. Theodore Markettos and Adam Boileau. "Hit by a Bus:Physical Access Attacks with Firewire". 2006. <https://security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-440: Expected Behavior Violation

Weakness ID: 440
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
A feature, API, or function does not perform according to its specification.
+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.684Incorrect Provision of Specified Functionality
Section HelpThis table 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 "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
Operation
+ Applicable Platforms
Section HelpThis listing shows 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)

+ Common Consequences
Section HelpThis table 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
Other

Technical Impact: Quality Degradation; Varies by Context

+ Observed Examples
ReferenceDescription
Program uses large timeouts on "undeserving" to compensate for inconsistency of support for linked lists.
"strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error?
Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
+ Notes

Theoretical

The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExpected behavior violation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relevant_Properties, Theoretical_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Description, Observed_Examples, Theoretical_Notes

CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information

Weakness ID: 1258
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
+ Extended Description

Security sensitive values, keys, intermediate steps of cryptographic operations, etc. are stored in temporary registers in the hardware. If these values are not cleared when debug mode is entered they may be accessed by a debugger allowing sensitive information to be accessible by untrusted parties.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.200Exposure of Sensitive Information to an Unauthorized Actor
ChildOfBaseBase - 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.212Improper Removal of Sensitive Information Before Storage or Transfer
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Read Memory

Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

A cryptographic core in a System-On-a-Chip (SoC) is used for cryptographic acceleration and implements several cryptographic operations (e.g., computation of AES encryption and decryption, SHA-256, HMAC, etc.). The keys for these operations or the intermediate values are stored in registers internal to the cryptographic core. These internal registers are in the Memory Mapped Input Output (MMIO) space and are blocked from access by software and other untrusted agents on the SoC. These registers are accessible through the debug and test interface.

(bad code)
Example Language: Other 
In the above scenario, registers that store keys and intermediate values of cryptographic operations are not cleared when system enters debug mode. An untrusted actor running a debugger may read the contents of these registers and gain access to secret keys and other sensitive cryptographic information.
(good code)
Example Language: Other 
Whenever the chip enters debug mode, all registers containing security-sensitive data are be cleared rendering them unreadable.
+ Potential Mitigations

Phase: Architecture and Design

Whenever debug mode is enabled, all registers containing sensitive assets must be cleared.

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Related_Attack_Patterns, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Sensitive Information Uncleared During Hardware Debug Flows

CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges

Weakness ID: 1316
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.
+ Extended Description

Various ranges can be defined in the system-address map, either in the memory or in Memory-Mapped-IO (MMIO) space. These ranges are usually defined using special range registers that contain information, such as base address and size. Address decoding is the process of determining for which range the incoming transaction is destined. To ensure isolation, ranges containing secret data are access-control protected.

Occasionally, these ranges could overlap. The overlap could either be intentional (e.g. due to a limited number of range registers or limited choice in choosing size of the range) or unintentional (e.g. introduced by errors). Some hardware designs allow dynamic remapping of address ranges assigned to peripheral MMIO ranges. In such designs, intentional address overlaps can be created through misconfiguration by malicious software. When protected and unprotected ranges overlap, an attacker could send a transaction and potentially compromise the protections in place, violating the principle of least privilege.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1203Peripherals, On-chip Fabric, and Interface/IO Problems
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Bus/Interface Hardware (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control
Authorization

Technical Impact: Bypass Protection Mechanism; Read Memory; Modify Memory

Medium
+ Demonstrative Examples

Example 1

An on-chip fabric supports a 64KB address space that is memory-mapped. The fabric has two range registers that support creation of two protected ranges with specific size constraints--4KB, 8KB, 16KB or 32KB. Assets that belong to user A require 4KB, and those of user B require 20KB. Registers and other assets that are not security-sensitive require 40KB. One range register is configured to program 4KB to protect user A’s assets. Since a 20KB range cannot be created with the given size constraints, the range register for user B’s assets is configured as 32KB. The rest of the address space is left as open. As a result, some part of untrusted and open-address space overlaps with user B range.

The fabric does not support least privilege, and an attacker can send a transaction to the overlapping region to tamper with user B data.

Since range B only requires 20KB but is allotted 32KB, there is 12KB of reserved space. Overlapping this region of user B data, where there are no assets, with the untrusted space will prevent an attacker from tampering with user B data.

+ Observed Examples
ReferenceDescription
Attacker can modify MCHBAR register to overlap with an attacker-controlled region, which modification prevents the SENTER instruction from properly applying VT-d protection while a Measured Launch Environment is being launched.
+ Potential Mitigations

Phase: Architecture and Design

When architecting the address map of the chip, ensure that protected and unprotected ranges are isolated and do not overlap. When designing, ensure that ranges hardcoded in Register-Transfer Level (RTL) do not overlap.

Phase: Implementation

Ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, then ensure that no assets are present in the overlapped portion.

Phase: Testing

Validate mitigation actions with robust testing.
+ Detection Methods

Automated Dynamic Analysis

Review address map in specification to see if there are any overlapping ranges.

Effectiveness: High

Manual Static Analysis

Negative testing of access control on overlapped ranges.

Effectiveness: High

+ Notes

Maintenance

As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.
+ References
[REF-1137] Yuriy Bulygin, Oleksandr Bazhaniuk, Andrew Furtak, John Loucaides, Mikhail Gorobets. "BARing the System – New vulnerabilities in Coreboot & UEFI-based Systems". 2017. <https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-06-01Arun Kanuparthi, Hareesh Khattri, Parbati Kumar MannaIntel Corporation
+ Modifications
Modification DateModifierOrganization
2021-10-28CWE Content TeamMITRE
updated Maintenance_Notes
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms

CWE-1209: Failure to Disable Reserved Bits

Weakness ID: 1209
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.
+ Extended Description

Reserved bits are labeled as such so they can be allocated for a later purpose. They are not to do anything in the current design. However, designers might want to use these bits to debug or control/configure a future capability to help minimize time to market (TTM). If the logic being controlled by these bits is still enabled in production, an adversary could use the logic to induce unwanted/unsupported behavior in the hardware.

+ Relationships
Section HelpThis table 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.710Improper Adherence to Coding Standards
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction
Section HelpThe 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 DesignThe Designer and Implementer have to make a conscious choice to do this
ImplementationThe Designer and Implementer have to make a conscious choice to do this
DocumentationIf documentation labels anything "for future use", "reserved", or the like, such labeling could indicate to an attacker a potential attack point
+ Applicable Platforms
Section HelpThis listing shows 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
Section HelpThis table 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
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

This type of weakness all depends on the capabilities of the logic being controlled or configured by the reserved bits
+ Demonstrative Examples

Example 1

An adversary may perform writes to reserve space in hopes to change the behavior of the hardware.

(bad code)
Example Language: Other 
// Assume an IP has address space 0x0-0x0F for its configuration registers, with the last one labeled reserved (i.e. 0x0F). Therefore inside the Finite State Machine (FSM), the code is as follows:

reg gpio_out = 0; //gpio should remain low for normal operation

case (register_address)
4'b1111 : //0x0F
begin
gpio_out = 1;
end

In the code above, the GPIO pin should remain low for normal operation. However, it can be asserted by accessing the reserved address space (0x0F). This may be a concern if the GPIO state is being used as an indicator of health (e.g. if asserted the hardware may respond by shutting down or resetting the system which may not be the correct action the system should perform).

(informative)
 
reg gpio_out = 0; //gpio should remain low for normal operation
case (register_address)
//4'b1111 : //0x0F
default: gpio_out = gpio_out;
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Include a feature to disable reserved bits.

Phase: Integration

Any writes to these reserve bits are blocked (e.g., ignored, access-protected, etc.), or an exception can be asserted.

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-06Brent ShermanIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Potential_Mitigations

CWE-1277: Firmware Not Updateable

Weakness ID: 1277
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product does not provide its users with the ability to update or patch its firmware to address any vulnerabilities or weaknesses that may be present.
+ Extended Description
Without the ability to patch or update firmware, consumers will be left vulnerable to exploitation of any known vulnerabilities, or any vulnerabilities that are discovered in the future. This can expose consumers to permanent risk throughout the entire lifetime of the device, which could be years or decades. Some external protective measures and mitigations might be employed to aid in preventing or reducing the risk of malicious attack, but the root weakness cannot be corrected.
+ Relationships
Section HelpThis table 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
ChildOfBaseBase - 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.1329Reliance on Component That is Not Updateable
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction
Section HelpThe 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
RequirementsRequirements development might not consider the importance of updates over the lifetime of the product, or might not choose the ability due to concerns such as expense or speed to market.
Architecture and DesignLack of planning during architecture development and design, or external pressures such as speed to market, could ignore the capability to update.
ImplementationThe weakness can appear through oversight during implementation.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control
Authentication
Authorization

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism; Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart

If an attacker can identify an exploitable vulnerability in one device that has no means of patching, the attack may be used against an entire class of devices.
Medium
+ Demonstrative Examples

Example 1

A refrigerator has an Internet interface for the official purpose of alerting the manufacturer when that refrigerator detects a fault. Because the device is attached to the Internet, the refrigerator is a target for hackers who may wish to use the device other potentially more nefarious purposes.

(bad code)
Example Language: Other 
The refrigerator has no means of patching and is hacked becoming a spewer of email spam.
(good code)
Example Language: Other 
The device automatically patches itself and provides considerable more protection against being hacked.
+ Observed Examples
ReferenceDescription
Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are "end-of-support" and cannot be patched (CWE-1277). [REF-1097]
A hardware "smart lock" has weak key generation that allows attackers to steal the key by BLE sniffing, but the device's firmware cannot be upgraded and hence remains vulnerable [REF-1095].
+ Potential Mitigations

Phase: Requirements

Specify requirements to include the ability to update the firmware. Include integrity checks and authentication to ensure that untrusted firmware cannot be installed.

Phase: Architecture and Design

Design the device to allow for updating the firmware. Ensure that the design specifies how to distribute the updates and ensure their integrity and authentication.

Phase: Implementation

Implement the necessary functionality to allow the firmware to be updated.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Create a new installable boot image of the current build with a minor version number change. Use the standard installation method to update the boot image. Verify that the minor version number has changed. Create a fake image. Verify that the boot updater will not install the fake image and generates an "invalid image" error message or equivalent.

Effectiveness: High

Architecture or Design Review

Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.

Effectiveness: Moderate

Manual Dynamic Analysis

Determine if there is a lack of a capability to update read-only memory (ROM) structure. This could manifest as a difference between the latest firmware version and the current version within the device.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Terminology

The "firmware" term does not have a single commonly-shared definition, so there may be variations in how this CWE entry is interpreted during mapping.
+ References
[REF-1095] Matthew Hughes. "Bad news: KeyWe Smart Lock is easily bypassed and can't be fixed". 2019-12-11. <https://www.theregister.com/2019/12/11/f_secure_keywe/>.
[REF-1096] Alex Scroxton. "Alarm bells ring, the IoT is listening". <https://www.computerweekly.com/news/252475324/Alarm-bells-ring-the-IoT-is-listening>.
[REF-1097] Brian Krebs. "Zyxel Flaw Powers New Mirai IoT Botnet Strain". 2020-03-20. <https://krebsonsecurity.com/2020/03/zxyel-flaw-powers-new-mirai-iot-botnet-strain/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-13Paul A. WortmanWells Fargo
+ Contributions
Contribution DateContributorOrganization
2021-10-12Paul A. WortmanWells Fargo
provided detection methods and observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Potential_Mitigations
2020-12-10CWE Content TeamMITRE
updated Description, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Common_Consequences, Description, Detection_Factors, Maintenance_Notes, Modes_of_Introduction, Observed_Examples, References, Relationships, Terminology_Notes, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Detection_Factors, Observed_Examples, Potential_Mitigations, Relationships

CWE CATEGORY: General Circuit and Logic Design Concerns

Category ID: 1199
+ Summary
Weaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - 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.1209Failure to Disable Reserved Bits
HasMemberBaseBase - 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.1221Incorrect Register Defaults or Module Parameters
HasMemberBaseBase - 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.1223Race Condition for Write-Once Attributes
HasMemberBaseBase - 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.1224Improper Restriction of Write-Once Bit Fields
HasMemberBaseBase - 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.1231Improper Prevention of Lock Bit Modification
HasMemberBaseBase - 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.1232Improper Lock Behavior After Power State Transition
HasMemberBaseBase - 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.1233Security-Sensitive Hardware Controls with Missing Lock Bit Protection
HasMemberBaseBase - 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.1234Hardware Internal or Debug Modes Allow Override of Locks
HasMemberBaseBase - 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.1245Improper Finite State Machines (FSMs) in Hardware Logic
HasMemberBaseBase - 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.1253Incorrect Selection of Fuse Values
HasMemberBaseBase - 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.1254Incorrect Comparison Logic Granularity
HasMemberBaseBase - 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.1261Improper Handling of Single Event Upsets
HasMemberBaseBase - 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.1298Hardware Logic Contains Race Conditions
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships

CWE-1270: Generation of Incorrect Security Tokens

Weakness ID: 1270
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.
+ Extended Description

Systems-On-a-Chip (SoC) (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify actions originated from various agents. These actions could be "read", "write", "program", "reset", "fetch", "compute", etc. Security Tokens are generated and assigned to every agent on the SoC that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Token based on its trust level or privileges. Incorrectly generated Security Tokens could result in the same token used for multiple agents or multiple tokens being used for the same agent. This condition could result in a Denial-of-Service (DoS) or the execution of an action that in turn could result in privilege escalation or unintended access.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1294Insecure Security Identifier Mechanism
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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: Modify Files or Directories; Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Gain Privileges or Assume Identity; Read Memory; Modify Memory; DoS: Crash, Exit, or Restart

High
+ Demonstrative Examples

Example 1

Consider a system with a register for storing an AES key for encryption or decryption. The key is 128 bits long implemented as a set of four 32-bit registers. The key registers are assets, and register, AES_KEY_ACCESS_POLICY, is defined to provide necessary access controls. The access-policy register defines which agents, using a Security Token, may access the AES-key registers. Each bit in this 32-bit register is used to define a Security Token. There could be a maximum of 32 Security Tokens that are allowed access to the AES-key registers. When set (bit = "1") bit number allows action from an agent whose identity matches that bit number. If Clear (bit = "0") the action is disallowed for the corresponding agent.

Let"s assume the system has two agents: a Main-controller and an Aux-controller. The respective Security Tokens are "1" and "2".

Register Description Default
AES_ENC_DEC_KEY_0 AES key [0:31] for encryption or decryption 0x00000000
AES_ENC_DEC_KEY_1 AES key [32:63] for encryption or decryption 0x00000000
AES_ENC_DEC_KEY_2 AES key [64:95] for encryption or decryption 0x00000000
AES_ENC_DEC_KEY_3 AES key [96:127] for encryption or decryption 0x00000000
AES_KEY_ACCESS_POLICY AES key access register [31:0] 0x00000002

An agent with a Security Token "1" has access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers. As per the above access policy, the AES-Key-access policy allows access to the AES-key registers if the security Token is "1".

(bad code)
Example Language: Other 
The SoC incorrectly generates Security Token "1" for every agent. In other words, both Main-controller and Aux-controller are assigned Security Token "1".

Both agents have access to the AES-key registers.

(good code)
Example Language: Other 
The SoC should correctly generate Security Tokens, assigning "1" to the Main-controller and "2" to the Aux-controller
+ Potential Mitigations

Phases: Architecture and Design; Implementation

  • Generation of Security Tokens should be reviewed for design inconsistency and common weaknesses.
  • Security-Token definition and programming flow should be tested in pre-silicon and post-silicon testing.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-03-06Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Modes_of_Introduction, Name, Potential_Mitigations, Relationships
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Generation of Incorrect Security Identifiers

CWE-1313: Hardware Allows Activation of Test or Debug Logic at Runtime

Weakness ID: 1313
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.
+ Extended Description

An adversary can take advantage of test or debug logic that is made accessible through the hardware during normal operation to modify the intended behavior of the system. For example, an accessible Test/debug mode may allow read/write access to any system data. Using error injection (a common test/debug feature) during a transmit/receive operation on a bus, data may be modified to produce an unintended message. Similarly, confidentiality could be compromised by such features allowing access to secrets.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction
Section HelpThe 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 DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
IntegrationSuch issues could be introduced during integration and identified later during Testing or System configuration phases.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Modify Memory; Read Memory; DoS: Crash, Exit, or Restart; DoS: Instability; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other); Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Alter Execution Logic; Quality Degradation; Unexpected State; Reduce Performance; Reduce Reliability

+ Potential Mitigations

Phase: Architecture and Design

Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.

Phase: Implementation

Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.

Phase: Integration

Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-08-06Brent ShermanAccellera IP Security Assurance (IPSA) Working Group
+ Modifications
Modification DateModifierOrganization
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-1276: Hardware Child Block Incorrectly Connected to Parent System

Weakness ID: 1276
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Signals between a hardware IP and the parent system design are incorrectly connected causing security risks.
+ Extended Description

Individual hardware IP must communicate with the parent system in order for the product to function correctly and as intended. If implemented incorrectly, while not causing any apparent functional issues, may cause security issues. For example, if the IP should only be reset by a system-wide hard reset, but instead the reset input is connected to a software-triggered debug mode reset (which is also asserted during a hard reset), integrity of data inside the IP can be violated.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1197Integration Issues
+ Modes Of Introduction
Section HelpThe 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
ImplementationThis weakness is introduced when integrating IP into a parent design.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Many SoCs use hardware to partition system resources between trusted and un-trusted entities. One example of this concept is the Arm TrustZone, in which the processor and all security-aware IP attempt to isolate resources based on the status of a privilege bit. This privilege bit is part of the input interface in all TrustZone-aware IP. If this privilege bit is accidentally grounded or left unconnected when the IP is instantiated, privilege escalation of all input data may occur.

(bad code)
Example Language: Verilog 

// IP definition

module tz_peripheral(clk, reset, data_in, data_in_security_level, ...);

input clk, reset;

input [31:0] data_in;

input data_in_security_level;

...

endmodule

// Instantiation of IP in a parent system

module soc(...)

...

tz_peripheral u_tz_peripheral(

.clk(clk),

.rst(rst),

.data_in(rdata),

//Copy-and-paste error or typo grounds data_in_security_level (in this example 0=secure, 1=non-secure) effectively promoting all data to “secure”)

.data_in_security_level(1'b0),

);

...

endmodule

In the Verilog code below, the security level input to the TrustZone aware peripheral is correctly driven by an appropriate signal instead of being grounded.

(good code)
Example Language: Verilog 

// Instantiation of IP in a parent system

module soc(...)

...

tz_peripheral u_tz_peripheral(

.clk(clk),

.rst(rst),

.data_in(rdata),

// This port is no longer grounded, but instead drive by the appropriate signal

.data_in_security_level(rdata_security_level),

);

...

endmodule

+ Potential Mitigations

Phase: Testing

System-level verification may be used to ensure that components are correctly connected and that design security requirements are not violated due to interactions between various IP blocks.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-22Nicole FernTortuga Logic
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Name, Potential_Mitigations
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Hardware Block Incorrectly Connected to Larger System

CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks

Weakness ID: 1234
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
System configuration protection may be bypassed during debug mode.
+ Extended Description

Device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set, disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If debug features supported by hardware or internal modes/system states are supported in the hardware design, modification of the lock protection may be allowed allowing access and modification of configuration information.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.667Improper Locking
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Bypass Protection Mechanism

Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.
High
+ Demonstrative Examples

Example 1

For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1.
However, it also allows override of the lock protection when scan_mode or debug_unlocked modes are active.

(bad code)
Example Language: Verilog 

module Locked_register_example

(

input [15:0] Data_in,

input Clk,

input resetn,

input write,

input Lock,

input scan_mode,

input debug_unlocked,

output reg [15:0] Data_out

);

reg lock_status;

always @(posedge Clk or negedge resetn)

if (~resetn) // Register is reset resetn

begin

lock_status <= 1'b0;

end

else if (Lock)

begin

lock_status <= 1'b1;

end

else if (~Lock)

begin

lock_status <= lock_status

end

always @(posedge Clk or negedge resetn)

if (~resetn) // Register is reset resetn

begin

Data_out <= 16'h0000;

end

else if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported for scan_mode & debug_unlocked

begin

Data_out <= Data_in;

end

else if (~write)

begin

Data_out <= Data_out;

end

endmodule

If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock protection may be bypassed.

(good code)
 
Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized users may enable these modes.
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security Lock bit protections should be reviewed for any bypass/override modes supported.
  • Any supported override modes either should be removed or protected using authenticated debug modes.
  • Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing.

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-1298: Hardware Logic Contains Race Conditions

Weakness ID: 1298
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
A race condition in the hardware logic results in undermining security guarantees of the system.
+ Extended Description

A race condition in logic circuits typically occurs when a logic gate gets inputs from signals that have traversed different paths while originating from the same source. Such inputs to the gate can change at slightly different times in response to a change in the source signal. This results in a timing error or a glitch (temporary or permanent) that causes the output to change to an unwanted state before settling back to the desired state. If such timing errors occur in access control logic or finite state machines that are implemented in security sensitive flows, an attacker might exploit them to circumvent existing protections.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity; Alter Execution Logic

+ Demonstrative Examples

Example 1

The code below shows a 2x1 multiplexor using logic gates. Though the code shown below results in the minimum gate solution, it is disjoint and causes glitches.

(bad code)
Example Language: Verilog 
// 2x1 Multiplexor using logic-gates

module glitchEx(
input wire in0, in1, sel,
output wire z
);

wire not_sel;
wire and_out1, and_out2;

assign not_sel = ~sel;
assign and_out1 = not_sel & in0;
assign and_out2 = sel & in1;

// Buggy line of code:
assign z = and_out1 | and_out2; // glitch in signal z

endmodule

The buggy line of code, commented above, results in signal 'z' periodically changing to an unwanted state. Thus, any logic that references signal 'z' may access it at a time when it is in this unwanted state. This line should be replaced with the line shown below in the Good Code Snippet which results in signal 'z' remaining in a continuous, known, state. Reference for the above code, along with waveforms for simulation can be found in the references below.

(good code)
Example Language: Verilog 
assign z <= and_out1 or and_out2 or (in0 and in1);

This line of code removes the glitch in signal z.

+ Potential Mitigations

Phase: Architecture and Design

Adopting design practices that encourage designers to recognize and eliminate race conditions, such as Karnaugh maps, could result in the decrease in occurrences of race conditions.

Phase: Implementation

Logic redundancy can be implemented along security critical paths to prevent race conditions. To avoid metastability, it is a good practice in general to default to a secure state in which access is not given to untrusted agents.
+ References
[REF-1115] Meher Krishna Patel. "FPGA designs with Verilog (section 7.4 Glitches)". <https://verilogguide.readthedocs.io/en/latest/verilog/fsm.html>.
[REF-1116] Clifford E. Cummings. "Non-Blocking Assignments in Verilog Synthesis, Coding Styles that Kill!". 2000. <http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels

Weakness ID: 1264
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.
+ Extended Description

Many high-performance on-chip bus protocols and processor data-paths employ separate channels for control and data to increase parallelism and maximize throughput. Bugs in the hardware logic that handle errors and security checks can make it possible for data to be forwarded before the completion of the security checks. If the data can propagate to a location in the hardware observable to an attacker, loss of data confidentiality can occur. 'Meltdown' is a concrete example of how de-synchronization between data and permissions checking logic can violate confidentiality requirements. Data loaded from a page marked as privileged was returned to the cpu regardless of current privilege level for performance reasons. The assumption was that the cpu could later remove all traces of this data during the handling of the illegal memory access exception, but this assumption was proven false as traces of the secret data were not removed from the microarchitectural state.

+ Relationships
Section HelpThis table 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
ChildOfBaseBase - 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.821Incorrect Synchronization
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.1037Processor Optimization Removal or Modification of Security-critical Code
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction
Section HelpThe 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 DesignThe weakness can be introduced in the data transfer or bus protocol itself or in the implementation.
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Read Memory; Read Application Data

+ Demonstrative Examples

Example 1

There are several standard on-chip bus protocols used in modern SoCs to allow communication between components. There are a wide variety of commercially available hardware IP implementing the interconnect logic for these protocols. A bus connects components which initiate/request communications such as processors and DMA controllers (bus masters) with peripherals which respond to requests. In a typical system, the privilege level or security designation of the bus master along with the intended functionality of each peripheral determine the security policy specifying which specific bus masters can access specific peripherals. This security policy (commonly referred to as a bus firewall) can be enforced using separate IP/logic from the actual interconnect responsible for the data routing.

(bad code)
Example Language: Other 
The firewall and data routing logic becomes de-synchronized due to a hardware logic bug allowing components that should not be allowed to communicate to share data. For example, consider an SoC with two processors. One is being used as a root of trust and can access a cryptographic key storage peripheral. The other processor (application cpu) may run potentially untrusted code and should not access the key store. If the application cpu can issue a read request to the key store which is not blocked due to de-synchronization of data routing and the bus firewall, disclosure of cryptographic keys is possible.
(good code)
Example Language: Other 
All data is correctly buffered inside the interconnect until the firewall has determined that the endpoint is allowed to receive the data.
+ Observed Examples
ReferenceDescription
Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.
+ Potential Mitigations

Phase: Architecture and Design

Thoroughly verify the data routing logic to ensure that any error handling or security checks effectively block illegal dataflows.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-22Nicole FernTortuga Logic
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Weakness_Ordinalities

CWE-1257: Improper Access Control Applied to Mirrored or Aliased Memory Regions

Weakness ID: 1257
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.
+ Extended Description

Hardware product designs often need to implement memory protection features that enable privileged software to define isolated memory regions and access control (read/write) policies. Isolated memory regions can be defined on different memory spaces in a design (e.g. system physical address, virtual address, memory mapped IO).

Each memory cell should be mapped and assigned a system address that the core software can use to read/write to that memory. It is possible to map the same memory cell to multiple system addresses such that read/write to any of the aliased system addresses would be decoded to the same memory cell.

This is commonly done in hardware designs for redundancy and simplifying address decoding logic. If one of the memory regions is corrupted or faulty, then that hardware can switch to using the data in the mirrored memory region. Memory aliases can also be created in the system address map if the address decoder unit ignores higher order address bits when mapping a smaller address region into the full system address.

A common security weakness that can exist in such memory mapping is that aliased memory regions could have different read/write access protections enforced by the hardware such that an untrusted agent is blocked from accessing a memory address but is not blocked from accessing the corresponding aliased memory address. Such inconsistency can then be used to bypass the access protection of the primary memory block and read or modify the protected memory.

An untrusted agent could also possibly create memory aliases in the system address map for malicious purposes if it is able to change the mapping of an address region or modify memory region sizes.

+ Relationships
Section HelpThis table 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.284Improper Access Control
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Memory Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

Microcontroller Hardware (Undetermined Prevalence)

Network on Chip Hardware (Undetermined Prevalence)

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Read Memory

High
Integrity

Technical Impact: Modify Memory

High
Availability

Technical Impact: DoS: Instability

High
+ Demonstrative Examples

Example 1

In a System-on-a-Chip (SoC) design the system fabric uses 16 bit addresses. An IP unit (Unit_A) has 4 kilobyte of internal memory which is mapped into a 16 kilobyte address range in the system fabric address map.

System Address Mapped to
0x0000 – 0x3FFF Unit_A registers : 0x0000 – 0x0FFF
0x4000 – 0xFFFF Other IPs & Memory

To protect the register controls in Unit_A unprivileged software is blocked from accessing addresses between 0x0000 – 0x0FFF.

The address decoder of Unit_A masks off the higher order address bits and decodes only the lower 12 bits for computing the offset into the 4 kilobyte internal memory space.

(bad code)
Example Language: Other 

In this design the aliased memory address ranges are these:


0x0000 – 0x0FFF

0x1000 – 0x1FFF

0x2000 – 0x2FFF

0x3000 – 0x3FFF

The same register can be accessed using four different addresses: 0x0000, 0x1000, 0x2000, 0x3000.

The system address filter only blocks access to range 0x0000 - 0x0FFF and does not block access to the aliased addresses in 0x1000 - 0x3FFF range. Thus, untrusted software can leverage the aliased memory addresses to bypass the memory protection.

(good code)
Example Language: Other 

In this design the aliased memory addresses (0x1000 - 0x3FFF) could be blocked from all system software access since they are not used by software.

Alternately, the MPU logic can be changed to apply the memory protection policies to the full address range mapped to Unit_A (0x0000 - 0x3FFF).

+ Potential Mitigations

Phases: Architecture and Design; Implementation

The checks should be applied for consistency access rights between primary memory regions and any mirrored or aliased memory regions. If different memory protection units (MPU) are protecting the aliased regions, their protected range definitions and policies should be synchronized.

Phases: Architecture and Design; Implementation

The controls that allow enabling memory aliases or changing the size of mapped memory regions should only be programmable by trusted software components.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-04-29Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Potential_Mitigations
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms

CWE-1262: Improper Access Control for Register Interface

Weakness ID: 1262
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.
+ Extended Description

Software commonly accesses peripherals in a System-on-Chip (SoC) or other device through a memory-mapped register interface. Malicious software could tamper with any security-critical hardware data that is accessible directly or indirectly through the register interface, which could lead to a loss of confidentiality and integrity.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction
Section HelpThe 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 DesignThis weakness may be exploited if the register interface design does not adequately protect hardware assets from software.
ImplementationMis-implementation of access control policies may inadvertently allow access to hardware assets through the register interface.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Read Memory; Read Application Data; Modify Memory; Modify Application Data; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Unexpected State; Alter Execution Logic

Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.
+ Demonstrative Examples

Example 1

The register interface provides software access to hardware functionality. This functionality is an attack surface. This attack surface may be used to run untrusted code on the system through the register interface. As an example, cryptographic accelerators require a mechanism for software to select modes of operation and to provide plaintext or ciphertext data to be encrypted or decrypted as well as other functions. This functionality is commonly provided through registers.

(bad code)
 
Cryptographic key material stored in registers inside the cryptographic accelerator can be accessed by software.
(good code)
 
Key material stored in registers should never be accessible to software. Even if software can provide a key, all read-back paths to software should be disabled.
+ Observed Examples
ReferenceDescription
virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.
Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.
+ Potential Mitigations

Phase: Architecture and Design

Design proper policies for hardware register access from software.

Phase: Implementation

Ensure that access control policies for register access are implemented in accordance with the specified design.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.

Effectiveness: Moderate

Manual Analysis

Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.

Effectiveness: Moderate

Simulation / Emulation

Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.

Effectiveness: Moderate

Formal Verification

Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.

Effectiveness: High

Automated Analysis

Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.

Effectiveness: High

Architecture or Design Review

Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.

Effectiveness: Moderate

Fuzzing

Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.

Effectiveness: Moderate

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-08Nicole FernTortuga Logic
+ Contributions
Contribution DateContributorOrganization
2021-10-11Anders Nordstrom, Alric AlthoffTortuga Logic
Provided detection methods and observed examples
2021-10-12Nicole FernRiscure
Provided detection methods
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Register Interface Allows Software Access to Sensitive Data or Security Settings

CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code

Weakness ID: 1274
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.
+ Extended Description

Adversaries could bypass the secure-boot process and execute their own untrusted, malicious boot code.

As a part of a secure-boot process, the read-only-memory (ROM) code for a System-on-Chip (SoC) or other system fetches bootloader code from Non-Volatile Memory (NVM) and stores the code in Volatile Memory (VM), such as dynamic, random-access memory (DRAM) or static, random-access memory (SRAM). The NVM is usually external to the SoC, while the VM is internal to the SoC. As the code is transferred from NVM to VM, it is authenticated by the SoC's ROM code.

If the volatile-memory-region protections or access controls are insufficient to prevent modifications from an adversary or untrusted agent, the secure boot may be bypassed or replaced with the execution of an adversary's code.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction
Section HelpThe 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 DesignThis weakness can be introduced during hardware architecture or design but can be identified later during testing.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control
Integrity

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity

High
+ Demonstrative Examples

Example 1

A typical SoC secure boot's flow includes fetching the next piece of code (i.e., the boot loader) from NVM (e.g., serial, peripheral interface (SPI) flash), and transferring it to DRAM/SRAM volatile, internal memory, which is more efficient.

(bad code)
 
The volatile-memory protections or access controls are insufficient.

The memory from where the boot loader executes can be modified by an adversary.

(good code)
 
A good architecture should define appropriate protections or access controls to prevent modification by an adversary or untrusted agent, once the bootloader is authenticated.
+ Observed Examples
ReferenceDescription
Locked memory regions may be modified through other interfaces in a secure-boot-loader image due to improper access control.
+ Potential Mitigations

Phase: Architecture and Design

Ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code.

Phase: Testing

Test the volatile-memory protections to ensure they are safe from modification or untrusted code.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Ensure the volatile memory is lockable or has locks. Ensure the volatile memory is locked for writes from untrusted agents or adversaries. Try modifying the volatile memory from an untrusted agent, and ensure these writes are dropped.

Effectiveness: High

Manual Analysis

Analyze the device using the following steps:

  • 1) Identify all fabric master agents that are active during system Boot Flow when initial code is loaded from Non-volatile storage to volatile memory.
  • 2) Identify the volatile memory regions that are used for storing loaded system executable program.
  • 3) During system boot, test programming the identified memory regions in step 2 from all the masters identified in step 1.

Only trusted masters should be allowed to write to the memory regions. For example, pluggable device peripherals should not have write access to program load memory regions.

Effectiveness: Moderate

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-04-25Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
suggested content improvements
2021-10-22Hareesh KhattriIntel Corporation
provided detection method
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Observed_Examples, Potential_Mitigations, Relationships, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Insufficient Protections on the Volatile Memory Containing Boot Code

CWE-1245: Improper Finite State Machines (FSMs) in Hardware Logic

Weakness ID: 1245
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.
+ Extended Description

The functionality and security of the system heavily depend on the implementation of FSMs. FSMs can be used to indicate the current security state of the system. Lots of secure data operations and data transfers rely on the state reported by the FSM. Faulty FSM designs that do not account for all states, either through undefined states (left as don't cares) or through incorrect implementation, might lead an attacker to drive the system into an unstable state from which the system cannot recover without a reset, thus causing a DoS. Depending on what the FSM is used for, an attacker might also gain additional privileges to launch further attacks and compromise the security guarantees.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.684Incorrect Provision of Specified Functionality
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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
Section HelpThis table 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
Availability
Access Control

Technical Impact: Unexpected State; DoS: Crash, Exit, or Restart; DoS: Instability; Gain Privileges or Assume Identity

+ Demonstrative Examples

Example 1

The FSM shown in the "bad" code snippet below assigns the output out based on the value of state, which is determined based on the user provided input, user_input.

(bad code)
Example Language: Verilog 
module fsm_1(out, user_input, clk, rst_n);
input [2:0] user_input;
input clk, rst_n;
output reg [2:0] out;
reg [1:0] state;
always @ (posedge clk or negedge rst_n )
begin
if (!rst_n)
state = 3'h0;
else
case (user_input)

3'h0:
3'h1:
3'h2:
3'h3: state = 2'h3;
3'h4: state = 2'h2;
3'h5: state = 2'h1;

endcase

end
out <= {1'h1, state};

endmodule

The case statement does not handle the scenario when user provides inputs of 3'h6 and 3'h7 using a default statement. Those inputs push the system to an undefined state and might cause a crash (denial of service) or any other unanticipated outcome.

Adding a default statement to handle undefined inputs mitigates this issue. This is shown in the "Good" code snippet below. The default statement is in bold.

(good code)
Example Language: Other 
case (user_input)
3'h0:
3'h1:
3'h2:
3'h3: state = 2'h3;
3'h4: state = 2'h2;
3'h5: state = 2'h1;
default: state = 2'h0;

endcase
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Define all possible states and handle all unused states through default statements. Ensure that system defaults to a secure state.

Effectiveness: High

+ References
[REF-1060] Farimah Farahmandi and Prabhat Mishra. "FSM Anomaly Detection using Formal Analysis". <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8119228&tag=1>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiThe Intel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-1332: Improper Handling of Faults that Lead to Instruction Skips

Weakness ID: 1332
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.
+ Extended Description

The operating conditions of hardware may change in ways that cause unexpected behavior to occur, including the skipping of security-critical CPU instructions. Generally, this can occur due to electrical disturbances or when the device operates outside of its expected conditions.

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, may lead to effectively 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.

Attackers can use fault injection techniques to alter the operating conditions of hardware so that security-critical instructions are skipped more frequently or more reliably than they would in a "natural" setting.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1384Improper Handling of Physical or Environmental Conditions
Section HelpThis table 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 "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
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1388Physical Access Issues and 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.1247Improper Protection Against Voltage and Clock Glitches
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows 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
Section HelpThis table 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
+ Demonstrative Examples

Example 1

A smart card contains authentication credentials that are used as authorization to enter a building. The credentials are only accessible when a correct PIN is presented to the card.

(bad code)
 
The card emits the credentials when a voltage anomaly is injected into the power line to the device at a particular time after providing an incorrect PIN to the card, causing the internal program to accept the incorrect PIN.

There are several ways this weakness could be fixed.

(good code)
 
  • add an internal filter or internal power supply in series with the power supply pin on the device
  • add sensing circuitry to reset the device if out of tolerance conditions are detected
  • add additional execution sensing circuits to monitor the execution order for anomalies and abort the action or reset the device under fault conditions
+ Observed Examples
ReferenceDescription
fault injection attack bypasses the verification mode, potentially allowing arbitrary code execution.
+ 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 behavior if instructions attempt to be skipped.

Phase: Architecture and Design

Identify mission critical secrets that should be wiped if faulting is detected, and design a mechanism to do the deletion.

Phase: Implementation

Add redundancy by performing an operation multiple times, either in space or time, and perform majority voting. Additionally, make conditional instruction timing unpredictable.

Phase: Implementation

Use redundant operations or canaries to detect faults.

Phase: Implementation

Ensure that fault mitigations are strong enough in practice. For example, a low power detection mechanism that 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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

This weakness can be found using automated static analysis once a developer has indicated which code paths are critical to protect.

Effectiveness: Moderate

Simulation / Emulation

This weakness can be found using automated dynamic analysis. Both emulation of a CPU with instruction skips, as well as RTL simulation of a CPU IP, can indicate parts of the code that are sensitive to faults due to instruction skips.

Effectiveness: Moderate

Manual Analysis

This weakness can be found using manual (static) analysis. The analyst has security objectives that are matched against the high-level code. This method is less precise than emulation, especially if the analysis is done at the higher level language rather than at assembly level.

Effectiveness: Moderate

+ Functional Areas
  • Power
+ References
[REF-1161] Josep Balasch, Benedikt Gierlichs and Ingrid Verbauwhede. "An In-depth and Black-box Characterization of the Effects of Clock Glitches on 8-bit MCUs". 2011 Workshop on Fault Diagnosis and Tolerance in Cryptography (IEEE). 2011-09. <https://ieeexplore.ieee.org/document/6076473>.
[REF-1222] Alexandre Menu, Jean-Max Dutertre, Olivier Potin and Jean-Baptiste Rigaud. "Experimental Analysis of the Electromagnetic Instruction Skip Fault Model". IEEE Xplore. 2020-04-30. <https://ieeexplore.ieee.org/document/9081261>.
[REF-1223] Niek Timmers, Albert Spruyt and Marc Witteman. "Controlling PC on ARM using Fault Injection". 2016-06-11. <https://www.riscure.com/uploads/2017/09/Controlling-PC-on-ARM-using-Fault-Injection.pdf>.
[REF-1224] Colin O'Flynn. "Attacking USB Gear with EMFI". Circuit Cellar. 2019-05. <https://www.totalphase.com/media/pdf/whitepapers/Circuit_Cellar_TP.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-10-14Jasper van WoudenbergRiscure
+ Contributions
Contribution DateContributorOrganization
2021-10-11Jasper van WoudenbergRiscure
Provided detection methods and feedback on demonstrative example
+ Modifications
Modification DateModifierOrganization
2021-01-11Jasper van WoudenbergRiscure
2021-03-15CWE Content TeamMITRE
updated Description, Functional_Areas, Potential_Mitigations, References
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Insufficient Protection Against Instruction Skipping Via Fault Injection

CWE-1351: Improper Handling of Hardware Behavior in Exceptionally Cold Environments

Weakness ID: 1351
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures.
+ Extended Description

The hardware designer may improperly anticipate hardware behavior when exposed to exceptionally cold conditions. As a result they may introduce a weakness by not accounting for the modified behavior of critical components when in extreme environments.

An example of a change in behavior is that power loss won't clear/reset any volatile state when cooled below standard operating temperatures. This may result in a weakness when the starting state of the volatile memory is being relied upon for a security decision. For example, a Physical Unclonable Function (PUF) may be supplied as a security primitive to improve confidentiality, authenticity, and integrity guarantees. However, when the PUF is paired with DRAM, SRAM, or another temperature sensitive entropy source, the system designer may introduce weakness by failing to account for the chosen entropy source's behavior at exceptionally low temperatures. In the case of DRAM and SRAM, when power is cycled at low temperatures, the device will not contain the bitwise biasing caused by inconsistencies in manufacturing and will instead contain the data from previous boot. Should the PUF primitive be used in a cryptographic construction which does not account for full adversary control of PUF seed data, weakness would arise.

This weakness does not cover "Cold Boot Attacks" wherein RAM or other external storage is super cooled and read externally by an attacker.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1384Improper Handling of Physical or Environmental Conditions
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1388Physical Access Issues and Concerns
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Embedded (Undetermined Prevalence)

Class: Microcomputer (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Integrity
Authentication

Technical Impact: Varies by Context; Unexpected State

Consequences of this weakness are highly contextual.
Low
+ Potential Mitigations

Phase: Architecture and Design

The system should account for security primitive behavior when cooled outside standard temperatures.
+ References
[REF-1181] Nikolaos Athanasios Anagnostopoulos, Tolga Arul, Markus Rosenstihl, André Schaller, Sebastian Gabmeyer and Stefan Katzenbeisser. "Low-Temperature Data Remnanence Attacks Against Intrinsic SRAM PUFs". 2018-10-15. <https://ieeexplore.ieee.org/abstract/document/8491873/>.
[REF-1182] Yuan Cao, Yunyi Guo, Benyu Liu, Wei Ge, Min Zhu and Chip-Hong Chang. "A Fully Digital Physical Unclonable Function Based Temperature Sensor for Secure Remote Sensing". 2018-10-11. <https://ieeexplore.ieee.org/abstract/document/8487347/>.
[REF-1183] Urbi Chatterjee, Soumi Chatterjee, Debdeep Mukhopadhyay and Rajat Subhra Chakraborty. "Machine Learning Assisted PUF Calibration for Trustworthy Proof of Sensor Data in IoT". 2020-06. <https://dl.acm.org/doi/abs/10.1145/3393628>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-10-23Paul A. WortmanWells Fargo
+ Modifications
Modification DateModifierOrganization
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships

CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges

Weakness ID: 1260
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
+ Extended Description

Isolated memory regions and access control (read/write) policies are used by hardware to protect privileged software. Software components are often allowed to change or remap memory region definitions in order to enable flexible and dynamically changeable memory management by system software.

If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege, privilege escalation may be available to attackers. The memory protection unit (MPU) logic can incorrectly handle such an address overlap and allow the lower-privilege software to read or write into the protected memory region, resulting in privilege escalation attack. An address overlap weakness can also be used to launch a denial of service attack on the higher-privilege software memory regions.

+ Relationships
Section HelpThis table 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.284Improper Access Control
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction
Section HelpThe 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 DesignSuch issues could be introduced during hardware architecture and design or implementation and identified later during the Testing phase.
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Memory Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Modify Memory; Read Memory; DoS: Instability

High
+ Demonstrative Examples

Example 1

For example, consider a design with a 16-bit address that has two software privilege levels: Privileged_SW and Non_privileged_SW. To isolate the system memory regions accessible by these two privilege levels, the design supports three memory regions: Region_0, Region_1, and Region_2.

Each region is defined by two 32 bit registers: its range and its access policy.

  • Address_range[15:0]: specifies the Base address of the region
  • Address_range[31:16]: specifies the size of the region
  • Access_policy[31:0]: specifies what types of software can access a region and which actions are allowed

Certain bits of the access policy are defined symbolically as follows:

  • Access_policy.read_np: if set to one, allows reads from Non_privileged_SW
  • Access_policy.write_np: if set to one, allows writes from Non_privileged_SW
  • Access_policy.execute_np: if set to one, allows code execution by Non_privileged_SW
  • Access_policy.read_p: if set to one, allows reads from Privileged_SW
  • Access_policy.write_p: if set to one, allows writes from Privileged_SW
  • Access_policy.execute_p: if set to one, allows code execution by Privileged_SW

For any requests from software, an address-protection filter checks the address range and access policies for each of the three regions, and only allows software access if all three filters allow access.

Consider the following goals for access control as intended by the designer:

  • Region_0 & Region_1: registers are programmable by Privileged_SW
  • Region_2: registers are programmable by Non_privileged_SW

The intention is that Non_privileged_SW cannot modify memory region and policies defined by Privileged_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privileged_SW is using.

(bad code)
 

Non_privileged_SW can program the Address_range register for Region_2 so that its address overlaps with the ranges defined by Region_0 or Region_1. Using this capability, it is possible for Non_privileged_SW to block any memory region from being accessed by Privileged_SW, i.e., Region_0 and Region_1.

This design could be improved in several ways.

(good code)
 
Ensure that software accesses to memory regions are only permitted if all three filters permit access. Additionally, the scheme could define a memory region priority to ensure that Region_2 (the memory region defined by Non_privileged_SW) cannot overlap Region_0 or Region_1 (which are used by Privileged_SW).
+ Observed Examples
ReferenceDescription
virtualization product allows compromise of hardware product by accessing certain remapping registers.
processor design flaw allows ring 0 code to access more privileged rings by causing a register window to overlap a range of protected system RAM [REF-1100]
+ Potential Mitigations

Phase: Architecture and Design

Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software.

Phase: Implementation

For all of the programmable memory protection regions, the memory protection unit (MPU) design can define a priority scheme.

For example: if three memory regions can be programmed (Region_0, Region_1, and Region_2), the design can enforce a priority scheme, such that, if a system address is within multiple regions, then the region with the lowest ID takes priority and the access-control policy of that region will be applied. In some MPU designs, the priority scheme can also be programmed by trusted software.

Hardware logic or trusted firmware can also check for region definitions and block programming of memory regions with overlapping addresses.

The memory-access-control-check filter can also be designed to apply a policy filter to all of the overlapping ranges, i.e., if an address is within Region_0 and Region_1, then access to this address is only granted if both Region_0 and Region_1 policies allow the access.

Effectiveness: High

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Manual Analysis

Create a high privilege memory block of any arbitrary size. Attempt to create a lower privilege memory block with an overlap of the high privilege memory block. If the creation attempt works, fix the hardware. Repeat the test.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes

Maintenance

As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.
+ References
[REF-1100] Christopher Domas. "The Memory Sinkhole". 2015-07-20. <https://github.com/xoreaxeaxeax/sinkhole/blob/master/us-15-Domas-TheMemorySinkhole-wp.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
suggested content improvements
2021-10-22Hareesh KhattriIntel Corporation
suggested observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Related_Attack_Patterns
2020-12-10CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Observed_Examples, Relationships, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms

CWE-1384: Improper Handling of Physical or Environmental Conditions

Weakness ID: 1384
Abstraction: Class
Structure: Simple
Presentation Filter:
+ Description
The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.
+ Extended Description

Hardware products are typically only guaranteed to behave correctly within certain physical limits or environmental conditions. Such products cannot necessarily control the physical or external conditions to which they are subjected. However, the inability to handle such conditions can undermine a product's security. For example, an unexpected physical or environmental condition may cause the flipping of a bit that is used for an authentication decision. This unexpected condition could occur naturally or be induced artificially by an adversary.

Physical or environmental conditions of concern are:

  • Atmospheric characteristics: extreme temperature ranges, etc.
  • Interference: electromagnetic interference (EMI), radio frequency interference (RFI), etc.
  • Assorted light sources: white light, ultra-violet light (UV), lasers, infrared (IR), etc.
  • Power variances: under-voltages, over-voltages, under-current, over-current, etc.
  • Clock variances: glitching, overclocking, clock stretching, etc.
  • Component aging and degradation
  • Materials manipulation: focused ion beams (FIB), etc.
  • Exposure to radiation: x-rays, cosmic radiation, etc.
+ Relationships
Section HelpThis table 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
ParentOfBaseBase - 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.1247Improper Protection Against Voltage and Clock Glitches
ParentOfBaseBase - 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.1261Improper Handling of Single Event Upsets
ParentOfBaseBase - 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.1332Improper Handling of Faults that Lead to Instruction Skips
ParentOfBaseBase - 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.1351Improper Handling of Hardware Behavior in Exceptionally Cold Environments
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1388Physical Access Issues and Concerns
+ Modes Of Introduction
Section HelpThe 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 DesignThe product's design might not consider checking and handling extreme conditions.
ManufacturingFor hardware manufacturing, sub-par components might be chosen that are not able to handle the expected environmental conditions.
+ Applicable Platforms
Section HelpThis listing shows 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.

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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

Technical Impact: Varies by Context; Unexpected State

Consequences of this weakness are highly dependent on the role of affected components within the larger product.
+ Potential Mitigations

Phase: Requirements

In requirements, be specific about expectations for how the product will perform when it exceeds physical and environmental boundary conditions, e.g., by shutting down.

Phases: Architecture and Design; Implementation

Where possible, include independent components that can detect excess environmental conditions and have the capability to shut down the product.

Phases: Architecture and Design; Implementation

Where possible, use shielding or other materials that can increase the adversary's workload and reduce the likelihood of being able to successfully trigger a security-related failure.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
+ References
[REF-1248] Securing Energy Infrastructure Executive Task Force (SEI ETF). "Categories of Security Vulnerabilities in ICS". ICS Communications / 2. Unreliability. 2022-03-09. <https://inl.gov/wp-content/uploads/2022/03/SEI-ETF-NCSV-TPT-Categories-of-Security-Vulnerabilities-ICS-v1_03-09-22.pdf>.
[REF-1255] Sergei P. Skorobogatov. "Semi-invasive attacks – A new approach to hardware security analysis". 2005-04. <https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2022-04-21CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2022-05-13Members of the Hardware CWE Special Interest Group
Provided feedback on descriptions
+ Modifications
Modification DateModifierOrganization
2022-06-28CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationships, Type
+ Previous Entry Names
Change DatePrevious Entry Name
2022-06-28Improper Handling of Extreme Physical Environment Conditions

CWE-1261: Improper Handling of Single Event Upsets

Weakness ID: 1261
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
+ Extended Description

Technology trends such as CMOS-transistor down-sizing, use of new materials, and system-on-chip architectures continue to increase the sensitivity of systems to soft errors. These errors are random, and their causes might be internal (e.g., interconnect coupling) or external (e.g., cosmic radiation). These soft errors are not permanent in nature and cause temporary bit flips known as single-event upsets (SEUs). SEUs are induced errors in circuits caused when charged particles lose energy by ionizing the medium through which they pass, leaving behind a wake of electron-hole pairs that cause temporary failures. If these failures occur in security-sensitive modules in a chip, it might compromise the security guarantees of the chip. For instance, these temporary failures could be bit flips that change the privilege of a regular user to root.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1384Improper Handling of Physical or Environmental Conditions
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.1254Incorrect Comparison Logic Granularity
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1388Physical Access Issues and Concerns
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Availability
Access Control

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability; Gain Privileges or Assume Identity; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

This is an example from [REF-1089]. See the reference for full details of this issue.

Parity is error detecting but not error correcting.

(bad code)
Example Language: Other 
Due to single-event upsets, bits are flipped in memories. As a result, memory-parity checks fail, which results in restart and a temporary denial of service of two to three minutes.
(good code)
Example Language: Other 
Using error-correcting codes could have avoided the restart caused by SEUs.

Example 2

In 2016, a security researcher, who was also a patient using a pacemaker, was on an airplane when a bit flip occurred in the pacemaker, likely due to the higher prevalence of cosmic radiation at such heights. The pacemaker was designed to account for bit flips and went into a default safe mode, which still forced the patient to go to a hospital to get it reset. The bit flip also inadvertently enabled the researcher to access the crash file, perform reverse engineering, and detect a hard-coded key. [REF-1101]

+ Potential Mitigations

Phase: Architecture and Design

Implement triple-modular redundancy around security-sensitive modules.

Phase: Architecture and Design

SEUs mostly affect SRAMs. For SRAMs storing security-critical data, implement Error-Correcting-Codes (ECC) and Address Interleaving.

+ References
[REF-1086] Fan Wang and Vishwani D. Agrawal. "Single Event Upset: An Embedded Tutorial". <https://www.eng.auburn.edu/~agrawvd/TALKS/tutorial_6pg.pdf>.
[REF-1087] P. D. Bradley and E. Normand. "Single Event Upsets in Implantable Cardioverter Defibrillators". <https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=736549>.
[REF-1088] Melanie Berg, Kenneth LaBel and Jonathan Pellish. "Single Event Effects in FPGA Devices 2015-2016". <https://ntrs.nasa.gov/search.jsp?R=20160007754>.
[REF-1089] Cisco. "Cisco 12000 Single Event Upset Failures Overview and Work Around Summary". <https://www.cisco.com/c/en/us/support/docs/field-notices/200/fn25994.html>.
[REF-1090] Cypress. "Different Ways to Mitigate Soft Errors in Asynchronous SRAMs - KBA90939". <https://community.cypress.com/docs/DOC-10826>.
[REF-1091] Ian Johnston. "Cosmic particles can change elections and cause plans to fall through the sky, scientists warn". <https://www.independent.co.uk/news/science/subatomic-particles-cosmic-rays-computers-change-elections-planes-autopilot-a7584616.html>.
[REF-1101] Anders B. Wilhelmsen, Eivind S. Kristiansen and Marie Moe. "The Hard-coded Key to my Heart - Hacking a Pacemaker Programmer". 2019-08-10. <https://anderbw.github.io/2019-08-10-DC27-Biohacking-pacemaker-programmer.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships

CWE-1331: Improper Isolation of Shared Resources in Network On Chip (NoC)

Weakness ID: 1331
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.
+ Extended Description

Typically, network on chips (NoC) have many internal resources that are shared between packets from different trust domains. These resources include internal buffers, crossbars and switches, individual ports, and channels. The sharing of resources causes contention and introduces interference between differently trusted domains, which poses a security threat via a timing channel, allowing attackers to infer data that belongs to a trusted agent. This may also result in introducing network interference, resulting in degraded throughput and latency.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.668Exposure of Resource to Wrong Sphere
ChildOfBaseBase - 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.653Improper Isolation or Compartmentalization
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.1189Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1203Peripherals, On-chip Fabric, and Interface/IO Problems
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.1189Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
+ Background Details

"Network-on-chip" (NoC) is a commonly-used term used for hardware interconnect fabrics used by multicore Systems-on-Chip (SoC). Communication between modules on the chip uses packet-based methods, with improved efficiency and scalability compared to bus architectures [REF-1241].

+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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

Security Hardware (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Availability

Technical Impact: DoS: Resource Consumption (Other); Varies by Context; Other

Attackers may infer data that belongs to a trusted agent. The methods used to perform this attack may result in noticeably increased resource consumption.
Medium
+ Demonstrative Examples

Example 1

Consider a NoC that implements a one-dimensional mesh network with four nodes. This supports two flows: Flow A from node 0 to node 3 (via node 1 and node 2) and Flow B from node 1 to node 2. Flows A and B share a common link between Node 1 and Node 2. Only one flow can use the link in each cycle.

One of the masters to this NoC implements a cryptographic algorithm (RSA), and another master to the NoC is a core that can be exercised by an attacker. The RSA algorithm performs a modulo multiplication of two large numbers and depends on each bit of the secret key. The algorithm examines each bit in the secret key and only performs multiplication if the bit is 1. This algorithm is known to be prone to timing attacks. Whenever RSA performs multiplication, there is additional network traffic to the memory controller. One of the reasons for this is cache conflicts.

Since this is a one-dimensional mesh, only one flow can use the link in each cycle. Also, packets from the attack program and the RSA program share the output port of the network-on-chip. This contention results in network interference, and the throughput and latency of one flow can be affected by the other flow's demand.

(attack code)
 
The attacker runs a loop program on the core they control, and this causes a cache miss in every iteration for the RSA algorithm. Thus, by observing network-traffic bandwidth and timing, the attack program can determine when the RSA algorithm is doing a multiply operation (i.e., when the secret key bit is 1) and eventually extract the entire, secret key.

There may be different ways to fix this particular weakness.

(good code)
Example Language: Other 
Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Providing marker flags to send through the interfaces coupled with examination of which users are able to read or manipulate the flags will help verify that the proper isolation has been achieved and is effective.

Effectiveness: Moderate

+ References
[REF-1155] Hassan M. G. Wassel, Ying Gao, Jason K. Oberg, Tedd Huffmire, Ryan Kastner, Frederic T. Chong, Timothy Sherwood. "SurfNoC: A Low Latency and Provably Non-Interfering Approach to Secure Networks-On-Chip". 2013. <http://cseweb.ucsd.edu/~kastner/papers/isca13-surfNOC.pdf>.
[REF-1241] Wikipedia. "Network on a chip". 2021-10-24. <https://en.wikipedia.org/wiki/Network_on_a_chip>.
[REF-1242] Subodha Charles and Prabhat Mishra. "A Survey of Network-on-Chip Security Attacks and Countermeasures". ACM Computing Surveys. 2021-10-24. 2021-05. <https://dl.acm.org/doi/fullHtml/10.1145/3450964>.
[REF-1245] Subodha Charles. "Design of Secure and Trustworthy Network-on-chip Architectures". 2020. <https://www.cise.ufl.edu/research/cad/Publications/charlesThesis.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-23Arun Kanuparthi, Hareesh Khattri, Parbati K. MannaIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-22Hareesh KhattriIntel Corporation
provided references and background information
+ Modifications
Modification DateModifierOrganization
2021-10-28CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Detection_Factors, Name, References, Relationships, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, References
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Improper Isolation of Shared Resources in Network On Chip

CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

Weakness ID: 1189
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
+ Extended Description

A System-On-a-Chip (SoC) has a lot of functionality, but it may have a limited number of pins or pads. A pin can only perform one function at a time. However, it can be configured to perform multiple different functions. This technique is called pin multiplexing. Similarly, several resources on the chip may be shared to multiplex and support different features or functions. When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access the assets intended to be accessed only by the trusted agents.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.668Exposure of Resource to Wrong Sphere
ChildOfBaseBase - 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.653Improper Isolation or Compartmentalization
ParentOfBaseBase - 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.1303Non-Transparent Sharing of Microarchitectural Resources
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.1331Improper Isolation of Shared Resources in Network On Chip (NoC)
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
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.1331Improper Isolation of Shared Resources in Network On Chip (NoC)
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Bypass Protection Mechanism

If resources being used by a trusted user are shared with an untrusted user, the untrusted user may be able to modify the functionality of the shared resource of the trusted user.
Integrity

Technical Impact: Quality Degradation

The functionality of the shared resource may be intentionally degraded.
+ Demonstrative Examples

Example 1

Consider the following SoC design. The Hardware Root of Trust (HRoT) local SRAM is memory mapped in the core{0-N} address space. The HRoT allows or disallows access to private memory ranges, thus allowing the sram to function as a mailbox for communication between untrusted and trusted HRoT partitions.

Hardware Root of Trust

We assume that the threat is from malicious software in the untrusted domain. We assume this software has access to the core{0-N} memory map and can be running at any privilege level on the untrusted cores. The capability of this threat in this example is communication to and from the mailbox region of SRAM modulated by the hrot_iface. To address this threat, information must not enter or exit the shared region of SRAM through hrot_iface when in secure or privileged mode.

+ Observed Examples
ReferenceDescription
Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

When sharing resources, avoid mixing agents of varying trust levels.

Untrusted agents should not share resources with trusted agents.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

Kernel integrity verification can help identify when shared resource configuration settings have been modified.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ References
[REF-1036] Ali Abbasi and Majid Hashemi. "Ghost in the PLC Designing an Undetectable Programmable Logic Controller Rootkit via Pin Control Attack". 2016. <https://www.blackhat.com/docs/eu-16/materials/eu-16-Abbasi-Ghost-In-The-PLC-Designing-An-Undetectable-Programmable-Logic-Controller-Rootkit-wp.pdf>.
[REF-1138] Stewart Smith. "CVE-2019-6260: Gaining control of BMC from the host processor". 2019. <https://www.flamingspork.com/blog/2019/01/23/cve-2019-6260:-gaining-control-of-bmc-from-the-host-processor/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-07-16Tortuga Logic
Provided Demonstrative Example for Hardware Root of Trust
2021-10-22Hareesh KhattriIntel Corporation
provided observed example
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Description, Observed_Examples, References, Relationships, Weakness_Ordinalities
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Improper Isolation of Shared Resources on System-on-Chip (SoC)

CWE-1232: Improper Lock Behavior After Power State Transition

Weakness ID: 1232
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.
+ Extended Description

Devices may allow device configuration controls which need to be programmed after device power reset via a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. This action is commonly implemented using a programmable lock bit, which, when set, disables writes to a protected set of registers or address regions.

After a power state transition, the lock bit is set to unlocked. Some common weaknesses that can exist in such a protection scheme are that the lock gets cleared, the values of the protected registers get reset, or the lock become programmable.

+ Relationships
Section HelpThis table 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
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.667Improper Locking
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1206Power, Clock, and Reset Concerns
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Modify Memory

High
+ Demonstrative Examples

Example 1

Consider the memory configuration settings of a system that uses DDR3 DRAM memory. Protecting the DRAM memory configuration from modification by software is required to ensure that system memory access control protections cannot be bypassed. This can be done by using lock bit protection that locks all of the memory configuration registers. The memory configuration lock can be set by the BIOS during the boot process.

If such a system also supports a rapid power on mode like hibernate, the DRAM data must be saved to a disk before power is removed and restored back to the DRAM once the system powers back up and before the OS resumes operation after returning from hibernate.

To support the hibernate transition back to the operating state, the DRAM memory configuration must be reprogrammed even though it was locked previously. As the hibernate resume does a partial reboot, the memory configuration could be altered before the memory lock is set. Functionally the hibernate resume flow requires a bypass of the lock-based protection. The memory configuration must be securely stored and restored by trusted system firmware. Lock settings and system configuration must be restored to the same state it was in before the device entered into the hibernate mode.

+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security Lock bit protections should be reviewed for behavior across supported power state transitions.
  • Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing including testing across power transitions.

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Description

CWE-1323: Improper Management of Sensitive Trace Data

Weakness ID: 1323
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
Trace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents.
+ Extended Description

To facilitate verification of complex System-on-Chip (SoC) designs, SoC integrators add specific IP blocks that trace the SoC's internal signals in real-time. This infrastructure enables observability of the SoC's internal behavior, validation of its functional design, and detection of hardware and software bugs. Such tracing IP blocks collect traces from several sources on the SoC including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then aggregated inside trace IP block and forwarded to trace sinks, such as debug-trace ports that facilitate debugging by external hardware and software debuggers.

Since these traces are collected from several security-sensitive sources, they must be protected against untrusted debuggers. If they are stored in unprotected memory, an untrusted software debugger can access these traces and extract secret information. Additionally, if security-sensitive traces are not tagged as secure, an untrusted hardware debugger might access them to extract confidential information.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction
Section HelpThe 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 Design
Implementation
+ Applicable Platforms
Section HelpThis listing shows 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
Section HelpThis table 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

Technical Impact: Read Memory

An adversary can read secret values if they are captured in debug traces and stored unsafely.
+ Demonstrative Examples

Example 1

In a SoC, traces generated from sources include security-sensitive IP blocks such as CPU (with tracing information such as instructions executed and memory operands), on-chip fabric (e.g., memory-transfer signals, transaction type and destination, and on-chip-firewall-error signals), power-management IP blocks (e.g., clock- and power-gating signals), and cryptographic coprocessors (e.g., cryptographic keys and intermediate values of crypto operations), among other non-security-sensitive IP blocks including timers and other functional blocks. The collected traces are then forwarded to the debug and trace interface used by the external hardware debugger.

(bad code)
Example Language: Other 
The traces do not have any privilege level attached to them. All collected traces can be viewed by any debugger (i.e., SoC designer, OEM debugger, or end user).
(good code)
Example Language: Other 
Some of the traces are SoC-design-house secrets, while some are OEM secrets. Few are end-user secrets and the rest are not security-sensitive. Tag all traces with the appropriate, privilege level at the source. The bits indicating the privilege level must be immutable in their transit from trace source to the final, trace sink. Debugger privilege level must be checked before providing access to traces.
+ Potential Mitigations

Phase: Implementation

Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.
+ References
[REF-1150] Jerry Backer, David Hely and Ramesh Karri. "Secure design-for-debug for Systems-on-Chip". 2015-10-06. <https://ieeexplore.ieee.org/document/7342418>.
[REF-1151] Jerry Backer, David Hely and Ramesh Karri. "Secure and Flexible Trace-Based Debugging of Systems-on-Chip". 2016-12. <https://dl.acm.org/doi/pdf/10.1145/2994601>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-07-20Hareesh Khattri, Parbati K. Manna, and Arun KanuparthiThe Intel Corporation
+ Modifications
Modification DateModifierOrganization
2021-10-28CWE Content TeamMITRE
updated Common_Consequences

CWE-1263: Improper Physical Access Control

Weakness ID: 1263
Abstraction: Class
Structure: Simple
Presentation Filter:
+ Description
The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.
+ Extended Description
Sections of a product intended to have restricted access may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product.
+ Relationships
Section HelpThis table 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.284Improper Access Control
ParentOfBaseBase - 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.1243Sensitive Non-Volatile Information Not Protected During Debug
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.1191On-Chip Debug and Test Interface With Improper Access Control
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.1243Sensitive Non-Volatile Information Not Protected During Debug
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction
Section HelpThe 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 DesignThis weakness can arise if design decisions are made that do not align with the intended physical protection of the product
ManufacturingWhile the architecture and design phase of the product may have accurately met the intended robustness for product physical protections, this phase may introduce the weakness through errors in physically manufacturing the product.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Varies by Context

+ Potential Mitigations

Phase: Architecture and Design

Specific protection requirements depend strongly on contextual factors including the level of acceptable risk associated with compromise to the product's protection mechanism. Designers could incorporate anti-tampering measures that protect against or detect when the product has been tampered with.

Phase: Testing

The testing phase of the lifecycle should establish a method for determining whether the protection mechanism is sufficient to prevent unauthorized access.

Phase: Manufacturing

Ensure that all protection mechanisms are fully activated at the time of manufacturing and distribution.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-28CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Description, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Description
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Insufficient Physical Protection Mechanism

CWE-1231: Improper Prevention of Lock Bit Modification

Weakness ID: 1231
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.
+ Extended Description

In integrated circuits and hardware intellectual property (IP) cores, device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification.

This behavior is commonly implemented using a trusted lock bit. When set, the lock bit disables writes to a protected set of registers or address regions. Design or coding errors in the implementation of the lock bit protection feature may allow the lock bit to be modified or cleared by software after it has been set. Attackers might be able to unlock the system and features that the bit is intended to protect.

+ Relationships
Section HelpThis table 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.284Improper Access Control
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction
Section HelpThe 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 DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
Section HelpThis listing shows 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: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table 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
Access Control

Technical Impact: Modify Memory

Registers protected by lock bit can be modified even when lock is set.
High
+ Demonstrative Examples

Example 1

Consider the example design below for a digital thermal sensor that detects overheating of the silicon and triggers system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by firmware, and then the register needs to be locked (TEMP_SENSOR_LOCK).

(bad code)
Example Language: Other 
Register Field description
CRITICAL_TEMP_LIMIT [31:8] Reserved field; Read only; Default 0

[7:0] Critical temp 0-255 Centigrade; Read-write-lock; Default 125
TEMP_SENSOR_CALIB [31:0] Thermal sensor calibration data. Slope value used to map sensor reading to degrees Centigrade.
TEMP_SENSOR_LOCK [31:1] Reserved field; Read only; Default 0

[0] Lock bit, locks CRITICAL_TEMP_LIMIT and TEMP_SENSOR_CALIB registers; Write-1-once; Default 0
TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0

[1] Enable hardware shutdown on critical temperature detection; Read-write; Default 0
CURRENT_TEMP [31:8] Reserved field; Read only; Default 0

[7:0] Current Temp 0-255 Centigrade; Read-only; Default 0

In this example, note that if the system heats to critical temperature, the response of the system is controlled by the TEMP_HW_SHUTDOWN bit [1], which is not lockable. Thus, the intended security property of the critical temperature sensor cannot be fully protected, since software can misconfigure the TEMP_HW_SHUTDOWN register even after the lock bit is set to disable the shutdown response.

(good code)
 

To fix this weakness, one could change the TEMP_HW_SHUTDOWN field to be locked by TEMP_SENSOR_LOCK.

TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0

[1] Enable hardware shutdown on critical temperature detection; Read-write-Lock; Default 0

[0] Locked by TEMP_SENSOR_LOCK
+ Observed Examples
ReferenceDescription
chip reset clears critical read/write lock permissions for RSA function
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security lock bit protections must be reviewed for design inconsistency and common weaknesses.
  • Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.

Effectiveness: High

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Set the lock bit. Power cycle the device. Attempt to clear the lock bit. If the information is changed, implement a design fix. Retest. Also, attempt to indirectly clear the lock bit or bypass it.

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1372ICS Supply Chain: OT Counterfeit and Malicious Corruption
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
reviewed content changes
2021-10-22Hareesh KhattriIntel Corporation
provided observed example
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, Relationships, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Improper Implementation of Lock Protection Registers

CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI)

Weakness ID: 1319
Abstraction: Base
Structure: Simple
Presentation Filter:
+ Description
The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.
+ Extended Description

Electromagnetic fault injection may allow an attacker to locally and dynamically modify the signals (both internal and external) of an integrated circuit. EM-FI attacks consist of producing a local, transient magnetic field near the device, inducing current in the device wires. A typical EMFI setup is made up of a pulse injection circuit that generates a high current transient in an EMI coil, producing an abrupt magnetic pulse which couples to the target producing faults in the device, which can lead to:

  • Bypassing security mechanisms such as secure JTAG or Secure Boot
  • Leaking device information
  • Modifying program flow
  • Perturbing secure hardware modules (e.g. random number generators)
+ Relationships
Section HelpThis table 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
Section HelpThis table 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 "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entrie