CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1194: Hardware Design (4.16)  
ID

CWE VIEW: Hardware Design

View ID: 1194
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
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
Stakeholder Description
Hardware Designers Hardware 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.
Educators Educators 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
+ Category Category - 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.
* Class Class - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Category Category - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Category Category - 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.
* Base Base - 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.
+ Category Category - 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.
* Base Base - 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.
* Class Class - 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
* Base Base - 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.
* Base Base - 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 Identifier for IP Block used in System-On-Chip (SOC) - (1192)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1192 (Improper Identifier for IP Block used in System-On-Chip (SOC))
The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.
* Base Base - 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.
* Variant Variant - 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. Insufficient Granularity of Address Regions Protected by Register Locks - (1222)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1222 (Insufficient Granularity of Address Regions Protected by Register Locks)
The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Class Class - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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 Source Identifier in Entity Transactions on a System-On-Chip (SOC) - (1302)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1302 (Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC))
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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Base Base - 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 Information during Transient Execution - (1420)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1420 (Exposure of Sensitive Information during Transient Execution)
A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.
* Base Base - 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 Information in Shared Microarchitectural Structures during Transient Execution - (1421)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)
A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.
* Base Base - 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 Information caused by Incorrect Data Forwarding during Transient Execution - (1422)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)
A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.
* Base Base - 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 Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)
Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.
+ Category Category - 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.
* Base Base - 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.
* Base Base - 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 Intellectual Property (IP) parameters to insecure values.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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 Preservation of Consistency Between Independent Representations of Shared State - (1250)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1250 (Improper Preservation of Consistency Between Independent Representations of Shared State)
The product has or supports multiple distributed components or sub-systems that are each required to keep their own local copy of shared data - such as state or cache - but the product does not ensure that all local copies remain consistent with each other.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Category Category - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Base Base - 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 Information during Transient Execution - (1420)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1420 (Exposure of Sensitive Information during Transient Execution)
A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.
* Base Base - 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 Information in Shared Microarchitectural Structures during Transient Execution - (1421)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)
A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.
* Base Base - 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 Information caused by Incorrect Data Forwarding during Transient Execution - (1422)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)
A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.
* Base Base - 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 Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)
Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.
+ Category Category - 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).
+ Base Base - 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.
* Variant Variant - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Base Base - 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 Information during Transient Execution - (1420)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1420 (Exposure of Sensitive Information during Transient Execution)
A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.
* Base Base - 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 Information in Shared Microarchitectural Structures during Transient Execution - (1421)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1421 (Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution)
A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.
* Base Base - 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 Information caused by Incorrect Data Forwarding during Transient Execution - (1422)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1422 (Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution)
A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.
* Base Base - 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 Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution - (1423)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1420 (Exposure of Sensitive Information during Transient Execution) > 1423 (Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution)
Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.
+ Category Category - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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 in Fabric Bridge - (1317)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1317 (Improper Access Control in Fabric Bridge)
The product uses a fabric bridge for transactions between two Intellectual Property (IP) blocks, but the bridge does not properly perform the expected privilege, identity, or other access control checks between those IP blocks.
* Base Base - 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.
+ Category Category - 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).
+ Base Base - 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
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. Power, Clock, Thermal, and Reset Concerns - (1206)
1194 (Hardware Design) > 1206 (Power, Clock, Thermal, 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.
* Base Base - 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, Thermal, 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.
* Base Base - 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, Thermal, 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.
* Base Base - 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) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)
The security-sensitive hardware module contains semiconductor defects.
* Variant Variant - 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, Thermal, 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.
* Base Base - 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, Thermal, 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.
* Base Base - 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, Thermal, 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.
* Base Base - 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, Thermal, 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.
* Base Base - 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, Thermal, 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.
* Base Base - 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 Outbound Error Messages and Alert Signals - (1320)
1194 (Hardware Design) > 1206 (Power, Clock, Thermal, and Reset Concerns) > 1320 (Improper Protection for Outbound Error Messages and Alert Signals)
Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.
* Base Base - 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, Thermal, 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.
* Base Base - 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, Thermal, and Reset Concerns) > 1338 (Improper Protections Against Hardware Overheating)
A hardware device is missing or has inadequate protection features to prevent overheating.
+ Category Category - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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. Cleartext Transmission of Sensitive Information - (319)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 319 (Cleartext Transmission of Sensitive Information)
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Category Category - 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.
* Base Base - 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.
* Base Base - 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.
* Class Class - 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.
* Class Class - 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.
* Base Base - 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.
+ Base Base - 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.
* Variant Variant - 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.
* Base Base - 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. Reliance on Component That is Not Updateable - (1329)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1329 (Reliance on Component That is Not Updateable)
The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.
* Class Class - 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. Reliance on Insufficiently Trustworthy Component - (1357)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1357 (Reliance on Insufficiently Trustworthy Component)
The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.
+ Category Category - 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.
* Class Class - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Base Base - 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.
* Variant Variant - 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.
* Base Base - 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.
* Base Base - 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.
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.
+ 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 view Total CWEs
Weaknesses 108 out of 940
Categories 13 out of 374
Views 0 out of 51
Total 121 out of 1365
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-12-27
(CWE 4.0, 2020-02-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2022-06-28 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

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
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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.

+ 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.
Scope Impact Likelihood
Access Control
Confidentiality
Integrity

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

+ Potential Mitigations

Phase: Implementation

Implement the access control check first. Access should only be given to asset if agent is authorized.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Pillar Pillar - 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. 284 Improper Access Control
ChildOf Class Class - 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. 696 Incorrect Behavior Order
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1198 Privilege 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.
Phase Note
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: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

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

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

(good code)
Example Language: Verilog 
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

+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1410 Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-12
(CWE 4.1, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2020-08-20 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Related_Attack_Patterns
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples

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

Weakness ID: 1282
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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.

+ 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.
Scope Impact Likelihood
Integrity

Technical Impact: Varies by Context

+ Potential Mitigations

Phase: Implementation

All immutable code or data should be programmed into ROM or write-once memory.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Class Class - 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. 668 Exposure of Resource to Wrong Sphere
CanPrecede Base Base - 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. 471 Modification of Assumed-Immutable Data (MAID)
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1202 Memory 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.
Phase Note
Implementation Keys, 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: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

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


+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ 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 Date Submitter Organization
2020-05-15
(CWE 4.1, 2020-02-24)
Nicole Fern Cycuity (originally submitted as Tortuga Logic)
+ Modifications
Modification Date Modifier Organization
2020-08-20 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Name
2021-03-15 CWE Content Team MITRE
updated Maintenance_Notes
2021-07-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2022-04-28 CWE Content Team MITRE
updated Related_Attack_Patterns
2023-01-31 CWE Content Team MITRE
updated Related_Attack_Patterns
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2020-08-20 Assumed-Immutable Data Stored in Writable Memory

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Extended Description

Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data.

Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries.

When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

+ 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.
Scope Impact Likelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Files or Directories

Anyone can read the information by gaining access to the channel being used for communication.
+ Potential Mitigations

Phase: Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Implementation

When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Class Class - 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. 311 Missing Encryption of Sensitive Data
ParentOf Variant Variant - 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. 5 J2EE Misconfiguration: Data Transmission Without Encryption
ParentOf Variant Variant - 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. 614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
Section Help This 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 "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - 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. 311 Missing Encryption of Sensitive Data
Section Help This 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 "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1207 Debug 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.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.
Operation
System Configuration
+ 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: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();
}
catch (IOException e) {
//...
}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.


Example 2

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors used cleartext transmission of sensitive information in their OT products.


Example 3

A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed.


Example 4

The following Azure CLI command lists the properties of a particular storage account:

(informative)
Example Language: Shell 
az storage account show -g {ResourceGroupName} -n {StorageAccountName}

The JSON result might be:

(bad code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
}

The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.).

Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as:

(good code)
Example Language: Shell 
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true:

(good code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
}

Note: to enable secure transfer using Azure's Portal instead of the command line:

  1. Open the Create storage account pane in the Azure portal.
  2. In the Advanced page, select the Enable secure transfer checkbox.


+ Observed Examples
Reference Description
Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
Building Controller uses a protocol that transmits authentication credentials in plaintext.
Programmable Logic Controller (PLC) sends password in plaintext.
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 818 OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf ViewView - 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). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Plaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011) SEC06-J Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011) SER02-J Sign then seal sensitive objects before sending them outside a trust boundary
Software Fault Patterns SFP23 Exposed Data
ISA/IEC 62443 Part 3-3 Req SR 4.1
ISA/IEC 62443 Part 4-2 Req CR 4.1B
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Sections 3.1 and 3.10. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.
[REF-1309] Microsoft. "Require secure transfer to ensure secure connections". 2022-07-24. <https://learn.microsoft.com/en-us/azure/storage/common/storage-require-secure-transfer>. URL validated: 2023-01-24.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-01-24 Accellera IP Security Assurance (IPSA) Working Group Accellera Systems Initiative
Submitted original contents of CWE-1324 and reviewed its integration into this entry.
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated References
2010-04-05 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21 CWE Content Team MITRE
updated Detection_Factors, Relationships
2010-12-13 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23 CWE Content Team MITRE
updated Abstraction
2018-03-27 CWE Content Team MITRE
updated References, Relationships, Type
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Description, Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Plaintext Transmission of Sensitive Information

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

Weakness ID: 1255
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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.

+ 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.
Scope Impact Likelihood
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.
+ 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.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Base Base - 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. 1300 Improper Protection of Physical Side Channels
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1206 Power, Clock, Thermal, and Reset Concerns
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1388 Physical Access Issues and Concerns
PeerOf Base Base - 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. 1259 Improper 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.
Phase Note
Architecture and Design The design of the algorithm itself may intrinsically allow the power side channel attack to be effective
Implementation This 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: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ 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:
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.

Among various options for mitigating the string comparison is obscuring the power consumption 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.

(good code)
Example Language:
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

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: Verilog 
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: Verilog 
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
Reference Description
CMAC verification vulnerable to timing and power attacks.
+ Functional Areas
  • Power
+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1184] Wikipedia. "Power Analysis". <https://en.wikipedia.org/wiki/Power_analysis>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-05-29
(CWE 4.2, 2020-08-20)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2020-09-09 Accellera IP Security Assurance (IPSA) Working Group Accellera 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 Date Modifier Organization
2021-03-15 CWE Content Team MITRE
updated Functional_Areas, Maintenance_Notes, Relationships
2021-07-20 CWE Content Team MITRE
updated Demonstrative_Examples, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Maintenance_Notes, References, Relationships, Type
2022-06-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples

CWE CATEGORY: Core and Compute Issues

Category ID: 1201
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.
+ Membership
Nature Type ID Name
MemberOf ViewView - 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). 1194 Hardware Design
HasMember 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. 1252 CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
HasMember 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. 1281 Sequence of Processor Instructions Leads to Unexpected Behavior
HasMember 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. 1342 Information Exposure through Microarchitectural State after Transient Execution
HasMember 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. 1420 Exposure of Sensitive Information during Transient Execution
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-12-27
(CWE 4.0, 2020-02-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2020-06-25 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Relationships

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

Weakness ID: 1252
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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.

+ 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.
Scope Impact Likelihood
Confidentiality
Integrity

Technical Impact: Execute Unauthorized Code or Commands

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

+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Pillar Pillar - 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. 284 Improper Access Control
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1201 Core 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.
Phase Note
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: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Microcontroller Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

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


+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1076] ARM. "Cortex-R4 Manual". <https://developer.arm.com/Processors/Cortex-M4>. URL validated: 2023-04-07.
[REF-1077] Intel. "MCS 51 Microcontroller Family User's Manual". <http://web.mit.edu/6.115/www/document/8051.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-13
(CWE 4.0, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2022-04-28 CWE Content Team MITRE
updated Applicable_Platforms, Related_Attack_Patterns
2022-06-28 CWE Content Team MITRE
updated Applicable_Platforms
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: Cross-Cutting Problems

Category ID: 1208
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.
+ Membership
Nature Type ID Name
MemberOf ViewView - 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). 1194 Hardware Design
HasMember 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. 440 Expected Behavior Violation
HasMember 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. 1053 Missing Documentation for Design
HasMember 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. 1059 Insufficient Technical Documentation
HasMember 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. 1263 Improper Physical Access Control
HasMember 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. 1277 Firmware Not Updateable
HasMember 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. 1301 Insufficient or Incomplete Data Removal within Hardware Component
HasMember 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. 1329 Reliance on Component That is Not Updateable
HasMember 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. 1357 Reliance on Insufficiently Trustworthy Component
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-12-27
(CWE 4.0, 2020-02-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2020-06-25 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

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

Weakness ID: 1279
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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.
+ 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.
Scope Impact Likelihood
Access Control
Confidentiality
Integrity
Availability
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

+ 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.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Class Class - 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. 665 Improper Initialization
ChildOf Pillar Pillar - 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. 691 Insufficient Control Flow Management
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1205 Security 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.
Phase Note
Architecture and Design
Implementation The 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: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Processor Hardware (Undetermined Prevalence)

Class: Not Technology-Specific (Undetermined Prevalence)

+ 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: Pseudocode 
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: Pseudocode 
If random_number_generator_self_test_passed() == TRUE
then Seed = get_random_number_from_RNG()
else enter_error_state()

+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-12
(CWE 4.1, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2020-08-20 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns
2021-03-15 CWE Content Team MITRE
updated Maintenance_Notes
2022-04-28 CWE Content Team MITRE
updated Applicable_Platforms
2022-06-28 CWE Content Team MITRE
updated Applicable_Platforms
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2020-08-20 Cryptographic Primitives used without Successful Self-Test

CWE CATEGORY: Debug and Test Problems

Category ID: 1207
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.
+ Membership
Nature Type ID Name
MemberOf ViewView - 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). 1194 Hardware Design
HasMember 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. 319 Cleartext Transmission of Sensitive Information
HasMember 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. 1191 On-Chip Debug and Test Interface With Improper Access Control
HasMember 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. 1234 Hardware Internal or Debug Modes Allow Override of Locks
HasMember 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. 1243 Sensitive Non-Volatile Information Not Protected During Debug
HasMember 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. 1244 Internal Asset Exposed to Unsafe Debug Access Level or State
HasMember 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. 1258 Exposure of Sensitive System Information Due to Uncleared Debug Information
HasMember 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. 1272 Sensitive Information Uncleared Before Debug/Power State Transition
HasMember 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. 1291 Public Key Re-Use for Signing both Debug and Production Code
HasMember 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. 1295 Debug Messages Revealing Unnecessary Information
HasMember 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. 1296 Incorrect Chaining or Granularity of Debug Components
HasMember 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. 1313 Hardware Allows Activation of Test or Debug Logic at Runtime
HasMember 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. 1323 Improper Management of Sensitive Trace Data
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-12-27
(CWE 4.0, 2020-02-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2020-06-25 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE-1295: Debug Messages Revealing Unnecessary Information

Weakness ID: 1295
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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".

+ 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.
Scope Impact Likelihood
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
+ Potential Mitigations

Phase: Implementation

Ensure that a debug message does not reveal any unnecessary information during the debug process for the intended response.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Class Class - 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. 200 Exposure of Sensitive Information to an Unauthorized Actor
PeerOf Base Base - 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. 209 Generation of Error Message Containing Sensitive Information
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1207 Debug 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.
Phase Note
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: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ 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
Reference Description
Digital Rights Management (DRM) capability for mobile platform leaks pointer information, simplifying ASLR bypass
Processor generates debug message that contains sensitive information ("addresses of memory transactions").
modem debug messages include cryptographic keys
+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1112] "Android Security Bulletin - December 2018". <https://source.android.com/security/bulletin/2018-12-01.html>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-05-31
(CWE 4.2, 2020-08-20)
Parbati Kumar Manna, Hareesh Khattri, Arun Kanuparthi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2021-07-20 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2022-10-13 CWE Content Team MITRE
updated References
2023-04-27 CWE Content Team MITRE
updated Observed_Examples, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Observed_Examples

CWE-1273: Device Unlock Credential Sharing

Weakness ID: 1273
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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 all employed by the same company, the risk of compromise of the credentials is greatly reduced. However, the risk is greater 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.

+ 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.
Scope Impact Likelihood
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.
+ 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.
+ Relationships
Section Help This 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)
Nature Type ID Name
ChildOf Class Class - 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. 200 Exposure of Sensitive Information to an Unauthorized Actor
Section Help This 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)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1195 Manufacturing 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.
Phase Note
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: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Other (Undetermined Prevalence)

Class: Not Technology-Specific (Undetermined Prevalence)

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

+ 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.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-05-29
(CWE 4.1, 2020-02-24)
Parbati Kumar Manna, Hareesh Khattri, Arun Kanuparthi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2020-08-20 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2022-10-13 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

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

Weakness ID: 1190
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - 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.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom 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.