CWE VIEW: Hardware Design
 ObjectiveThis 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
RelationshipsThe 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 - 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.   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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques) Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy. 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Protections on the Volatile Memory Containing Boot Code - (1274)1194 (Hardware Design) > 1196 (Security Flow Issues) > 1274 (Insufficient Protections on the Volatile Memory Containing Boot Code) The protections on the product's non-volatile memory containing boot code are insufficient to prevent the bypassing of secure boot or the execution of an untrusted, boot code chosen by an adversary. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 product does not properly isolate shared resources between trusted and untrusted agents. 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.System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers - (1192)1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1192 (System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers) The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components. 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. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Register Interface Allows Software Access to Sensitive Data or Security Settings - (1262)1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1262 (Register Interface Allows Software Access to Sensitive Data or Security Settings) Memory-mapped registers provide access to hardware functionality from software and if not properly secured can result in loss of confidentiality and integrity. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Security Identifier - (1302)1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1302 (Missing Security Identifier) The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Register Defaults or Module Parameters - (1221)1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1221 (Incorrect Register Defaults or Module Parameters) Hardware description language code incorrectly defines register defaults or hardware IP parameters to insecure values. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Implementation of Lock Protection Registers - (1231)1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1231 (Improper Implementation of Lock Protection Registers) The product incorrectly implements register lock bit protection features such that protected controls can be programmed even after the lock has been set. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Hardware Lock Protection for Security Sensitive Controls - (1233)1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1233 (Improper Hardware Lock Protection for Security Sensitive Controls) The product implements a register lock bit protection feature that permits security sensitive controls to modify the protected configuration. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 (Halt and Catch Fire) - (1281)1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1281 (Sequence of Processor Instructions Leads to Unexpected Behavior (Halt and Catch Fire)) Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed. 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 Security Identifier - (1302)1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1302 (Missing Security Identifier) The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) When a device releases a resource such as memory or a file for reuse by other entities, information contained in the resource is not fully cleared prior to reuse of the resource. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Security Checks in Fabric Bridge - (1317)1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1317 (Missing Security Checks in Fabric Bridge) A bridge that is connected to a fabric without security features forwards transactions to the slave without checking the privilege level of the master. Similarly, it does not check the hardware identity of the transaction received from the slave interface of the bridge. 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) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1319 (Improper Protection against Electromagnetic Fault Injection (EM-FI)) The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed. 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 - (1331)1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems) > 1331 (Improper Isolation of Shared Resources in Network On Chip) The product 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 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Physical Side Channels - (1300)1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 203 (Observable Discrepancy) > 1300 (Improper Protection Against Physical Side Channels) The product is missing protections or implements insufficient protections against information leakage through physical channels such as power consumption, electromagnetic emissions (EME), acoustic emissions, or other physical attributes. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Risky Cryptographic Primitive - (1240)1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1240 (Use of a Risky Cryptographic Primitive) This device implements a cryptographic algorithm using a non-standard or unproven cryptographic primitive. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.Power, Clock, and Reset Concerns - (1206)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level. 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, 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 or Improperly Implemented Protection Against Voltage and Clock Glitches - (1247)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1247 (Missing or Improperly Implemented Protection Against Voltage and Clock Glitches) The device does not contain or contains improperly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device. 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.Comparison Logic is Vulnerable to Power Side-Channel Attacks - (1255)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1255 (Comparison Logic is Vulnerable to Power Side-Channel Attacks) A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token. 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 Features Enable Physical Attacks from Software - (1256)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1256 (Hardware Features Enable Physical Attacks from Software) Software-controllable device functionality such as power and clock management permits unauthorized modification of memory or register bits. 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, 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation - (1304)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1304 (Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation) The product performs a power save/restore
operation, but it does not ensure that the integrity of
the configuration state is maintained and/or verified between
the beginning and ending of the operation. 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, 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Protection for Out of Bounds Signal Level Alerts - (1320)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1320 (Improper Protection for Out of Bounds Signal Level Alerts) Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.
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 Protection Against Instruction Skipping Via Fault Injection - (1332)1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1332 (Insufficient Protection Against Instruction Skipping Via Fault Injection) The device is missing or incorrectly
implements circuitry or sensors to detect and mitigate CPU
instruction skips that can be caused by fault injection. 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, and Reset Concerns) > 1338 (Improper Protections Against Hardware Overheating) A hardware device is missing or has inadequate protection features to prevent overheating. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Exposed Chip Debug and Test Interface With Insufficient or Missing Authorization - (1191)1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1191 (Exposed Chip Debug and Test Interface With Insufficient or Missing Authorization) The chip does not implement or does not correctly check whether users are authorized to access internal registers. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 to Sensitive Information Using Debug and Test Interfaces - (1244)1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1244 (Improper Access to Sensitive Information Using Debug and Test Interfaces) The product's physical debug and test interface protection does not block untrusted agents, resulting in unauthorized access to and potentially control of sensitive assets. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) Sensitive information may leak as a result of a debug or power state transition when information access restrictions change as a result of the transition. 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Sensitive Information Accessible by Physical Probing of JTAG Interface - (1324)1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1324 (Sensitive Information Accessible by Physical Probing of JTAG Interface) Sensitive information in clear text on the JTAG
interface may be examined by an eavesdropper, e.g.
by placing a probe device on the interface such as a logic
analyzer, or a corresponding software technique.
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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 - 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 to be designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor's ability to access these areas. 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) A product's firmware cannot be updated or patched, leaving weaknesses present with no means of repair and the product vulnerable to attack. 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) > 1208 (Cross-Cutting Problems) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques) Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy. 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 Physical Side Channels - (1300)1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1300 (Improper Protection Against Physical Side Channels) The product is missing protections or implements insufficient protections against information leakage through physical channels such as power consumption, electromagnetic emissions (EME), acoustic emissions, or other physical attributes. 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 - 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. NotesOther 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
Content History
View ComponentsA | 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
Presentation Filter:
DescriptionA product's hardware-based access control check occurs after the asset has been accessed. Extended DescriptionThe 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. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Verilog (Undetermined Prevalence) VHDL (Undetermined Prevalence) Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 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) endmoduledata_out = 0; elsedata_out = (grant_access) ? data_in : data_out; endassign grant_access = (usr_id == 3’h4) ? 1’b1 : 1’b0; This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1. (good code) Example Language: Verilog Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below. always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
data_out = 0; elseassign grant_access = (usr_id == 3’h4) ? 1’b1 : 1’b0; enddata_out = (grant_access) ? data_in : data_out; endmodule
Potential Mitigations
Related Attack Patterns
Content History
CWE-1282: Assumed-Immutable Data is Stored in Writable Memory
Presentation Filter:
DescriptionImmutable 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 DescriptionSecurity 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. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Cryptographic hash functions are commonly used to create unique fixed-length digests used to ensure the integrity of code and keys. A golden digest is stored on the device and compared to the digest computed from the data to be verified. If the digests match, the data has not been maliciously modified. If an attacker can modify the golden digest they then have the ability to store arbitrary data that passes the verification check. Hash digests used to verify public keys and early stage boot code should be immutable, with the strongest protection offered by hardware immutability. Potential Mitigations
Notes Content History
CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks
Presentation Filter:
DescriptionA 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 DescriptionThe 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. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Consider an example hardware module that checks a user-provided password (or PIN) to grant access to a user. The user-provided password is compared against a stored value byte-by-byte. (bad code) Example Language: Other static nonvolatile password_tries = NUM_RETRIES; do while (password_tries == 0) ; // Hang here if no more password tries password_ok = 0; for (i = 0; i < NUM_PW_DIGITS; i++) if (GetPasswordByte() == stored_password([i]) password_ok |= 1; // Power consumption is different here else password_ok |= 0; // than from here end if (password_ok > 0) password_tries = NUM_RETRIES; break_to_Ok_to_proceed password_tries--; while (true) // Password OK Since the algorithm uses a different number of 1's and 0's for password validation, a different amount of power is consumed for the good byte versus the bad byte comparison. Using this information, an attacker may be able to guess the correct password for that byte-by-byte iteration with several repeated attempts by stopping the password evaluation before it completes. (good code) Among various options for mitigating the string comparison is obscuring the power comsumption by having opposing bit flips during bit operations. Note that in this example, the initial change of the bit values could still provide power indication depending upon the hardware itself. This possibility needs to be measured for verification. static nonvolatile password_tries = NUM_RETRIES; do while (password_tries == 0) ; // Hang here if no more password tries password_tries--; // Put retry code here to catch partial retries password_ok = 0; for (i = 0; i < NUM_PW_DIGITS; i++) if (GetPasswordByte() == stored_password([i]) password_ok |= 0x10; // Power consumption here else password_ok |= 0x01; // is now the same here end if ((password_ok & 1) == 0) password_tries = NUM_RETRIES; break_to_Ok_to_proceed while (true) // Password OK Since the algorithm uses a different number of 1's and 0's for password validation, a different amount of power is consumed for the good byte versus the bad byte comparison. Using this information, an attacker may be able to guess the correct password for that byte-by-byte iteration with several repeated attempts by stopping the password evaluation before it completes. (good code) An alternative to the previous example is simply comparing the whole password simultaneously. static nonvolatile password_tries = NUM_RETRIES; do while (password_tries == 0) ; // Hang here if no more password tries password_tries--; // Put retry code here to catch partial retries for (i = 0; i < NUM_PW_DIGITS; i++) stored_password([i] = GetPasswordByte(); end if (stored_password == saved_password) password_tries = NUM_RETRIES; break_to_Ok_to_proceed while (true) // Password OK Since comparison is done atomically, there is no indication which bytes fail forcing the attacker to brute force the whole password at once. Note that other mitigations may exist such as masking - causing a large current draw to mask individual bit flips. Potential Mitigations
Functional Areas
Notes Content History
CWE CATEGORY: Core and Compute Issues
SummaryWeaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers. Membership
Content History
CWE-1252: CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
Presentation Filter:
DescriptionThe 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 DescriptionCPUs 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. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Microcontroller IP (Undetermined Prevalence) Processor IP (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 MCS51 Microcontroller (based on 8051) does not have a special bit to support write exclusivity. It also does not have an MMU/MPU support. The Cortex-M CPU has an optional MPU that supports up to 8 regions. (bad code) Example Language: Other The optional MPU is not configured.
If the MPU is not configured, then an attacker will be able to inject malicious data into memory and execute it. Potential Mitigations
Related Attack Patterns References
Content History
CWE CATEGORY: Cross-Cutting Problems
SummaryWeaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components. Membership
Content History
CWE-1279: Cryptographic Operations are run Before Supporting Units are Ready
Presentation Filter:
DescriptionPerforming cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result. Extended DescriptionMany 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. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Verilog (Undetermined Prevalence) VHDL (Undetermined Prevalence) Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Processor IP (Undetermined Prevalence) Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 The following pseudocode illustrates the weak encryption resulting from the use of a pseudo-random-number generator output. (bad code) Example Language: Other If random_number_generator_self_test_passed() == TRUE then Seed = get_random_number_from_RNG() else Seed = hardcoded_number In the example above, first a check of RNG ready is performed. If the check fails, the RNG is ignored and a hard coded value is used instead. The hard coded value severely weakens the encrypted output. (good code) Example Language: Other If random_number_generator_self_test_passed() == TRUE then Seed = get_random_number_from_RNG() else enter_error_state() Potential Mitigations
Related Attack Patterns
Content History
CWE CATEGORY: Debug and Test Problems
SummaryWeaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain. Membership
Content History
CWE-1295: Debug Messages Revealing Unnecessary Information
Presentation Filter:
DescriptionThe product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages. Extended DescriptionDebug 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”. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 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
Potential Mitigations
References
Content History
CWE-1273: Device Unlock Credential Sharing
Presentation Filter:
DescriptionThe 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 capablilities are not available. For cases where the chip designer, chip manufacturer (fabricator), and manufacturing and assembly testers are the all employed by the same company, the compromise of the credentials are greatly reduced. However, when the chip designer is employed by one company, the chip manufacturer is employed by another company (a foundry), and the assemblers and testers are employed by yet a third company. Since these different companies will need to perform various tests on the device to verify correct device function, they all need to share the unlock key. Unfortunately, the level of secrecy and policy might be quite different at each company, greatly increasing the risk of sensitive credentials being compromised. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages VHDL (Undetermined Prevalence) Verilog (Undetermined Prevalence) Class: Compiled (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Other (Undetermined Prevalence) Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 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 implenmented to reduce these risks. Potential Mitigations
NotesMaintenance This entry is still under development and will continue to see updates and content improvements. Related Attack Patterns
Content History
CWE-1190: DMA Device Enabled Too Early in Boot Phase
Presentation Filter:
DescriptionThe product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product. Extended DescriptionDMA is included in a number of devices because it allows data transfer between the computer and the connected device, using direct hardware access to read or write directly to main memory without any OS interaction. An attacker could exploit this to access secrets. Several virtualization-based mitigations have been introduced to thwart DMA attacks. These are usually configured/setup during boot time. However, certain IPs that are powered up before boot is complete (known as early boot IPs) may be DMA capable. Such IPs, if not trusted, could launch DMA attacks and gain access to assets that should otherwise be protected. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Potential Mitigations
Related Attack Patterns
References
Content History
CWE-440: Expected Behavior Violation
Presentation Filter:
DescriptionA feature, API, or function does not perform according to its specification. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Observed Examples
MembershipsThis 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.
NotesTheoretical The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software. Taxonomy Mappings
Content History
CWE-1191: Exposed Chip Debug and Test Interface With Insufficient or Missing Authorization
Presentation Filter:
DescriptionThe chip does not implement or does not correctly check whether users are authorized to access internal registers. Extended DescriptionA device's internal information may be accessed through a scan chain of interconnected internal registers usually through a JTAG interface. The JTAG interface provides access to these registers in a serial fashion in the form of a scan chain for the purposes of debugging programs running on a device. Since almost all information contained within a device may be accessed over this interface, device manufacturers typically insert some form of authentication and authorization to prevent unintended use of this sensitive information. This mechanism is implemented in addition to on-chip protections that are already present. If this control is not implemented or not implemented properly a user may be able to bypass on-chip protection mechanisms through debug interface. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 A home, WiFi-router device implements a login prompt which prevents an unauthorized user from issuing any commands on the device until appropriate credentials are provided. The credentials are protected on the device and are checked for strength against attack. (bad code) Example Language: Other If the JTAG interface on this device is not hidden by the manufacturer, the interface may be identified using tools such as JTAGulator. If it is hidden but not disabled, it can be exposed by physically wiring to the board. By issuing a halt command before the OS starts, the unauthorized user pauses the watchdog timer and prevents the router from restarting (once the watchdog timer would have expired). Having paused the router, an unauthorized user is able to execute code and inspect and modify data in the device even extracting all of the routers firmware. This allows the user to examine the router and potentially take over the router. JTAG is useful to chip and device manufacturers during design, testing, and production and is included in nearly every product. Without proper authentication and authorization, the interface may allow tampering with a product. (good code) Example Language: Other In order to prevent exposing the debugging interface, manufacturers might try to obfuscate JTAG interface or blow device internal fuses to disable the JTAG interface. Adding authentication and authorization to this interface makes use by unauthorized individuals much more difficult.. Observed Examples
Potential Mitigations
Notes Related Attack Patterns References
Content History
CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information
Presentation Filter:
DescriptionThe hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered. Extended DescriptionSecurity sensitive values, keys, intermediate steps of cryptographic operations, etc. are stored in temporary registers in the hardware. If these values are not cleared when debug mode is entered they may be accessed by a debugger allowing sensitive information to be accessible by untrusted parties. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 A cryptographic core in a System-On-a-Chip (SoC) is used for cryptographic acceleration and implements several cryptographic operations (e.g., computation of AES encryption and decryption, SHA-256, HMAC, etc.). The keys for these operations or the intermediate values are stored in registers internal to the cryptographic core. These internal registers are in the Memory Mapped Input Output (MMIO) space and are blocked from access by software and other untrusted agents on the SoC. These registers are accessible through the debug and test interface. (bad code) Example Language: Other In the above scenario, registers that store keys and intermediate values of cryptographic operations are not cleared when system enters debug mode. An untrusted actor running a debugger may read the contents of these registers and gain access to secret keys and other sensitive cryptographic information. (good code) Example Language: Other Whenever the chip enters debug mode, all registers containing security-sensitive data are be cleared rendering them unreadable. Potential Mitigations
Related Attack Patterns Content History
CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges
Presentation Filter:
DescriptionThe address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region. Extended DescriptionVarious ranges can be defined in the system-address map, either in the memory or in Memory-Mapped-IO (MMIO) space. These ranges are usually defined using special range registers that contain information, such as base address and size. Address decoding is the process of determining for which range the incoming transaction is destined. To ensure isolation, ranges containing secret data are access-control protected. Occasionally, these ranges could overlap. The overlap could either be intentional (e.g. due to a limited number of range registers or limited choice in choosing size of the range) or unintentional (e.g. introduced by errors). Some hardware designs allow dynamic remapping of address ranges assigned to peripheral MMIO ranges. In such designs, intentional address overlaps can be created through misconfiguration by malicious software. When protected and unprotected ranges overlap, an attacker could send a transaction and potentially compromise the protections in place, violating the principle of least privilege. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Bus/Interface IP (Undetermined Prevalence) Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 An on-chip fabric supports a 64KB address space that is memory-mapped. The fabric has two range registers that support creation of two protected ranges with specific size constraints--4KB, 8KB, 16KB or 32KB. Assets that belong to user A require 4KB, and those of user B require 20KB. Registers and other assets that are not security-sensitive require 40KB. One range register is configured to program 4KB to protect user A’s assets. Since a 20KB range cannot be created with the given size constraints, the range register for user B’s assets is configured as 32KB. The rest of the address space is left as open. As a result, some part of untrusted and open-address space overlaps with user B range. The fabric does not support least privilege, and an attacker can send a transaction to the overlapping region to tamper with user B data. Since range B only requires 20KB but is allotted 32KB, there is 12KB of reserved space. Overlapping this region of user B data, where there are no assets, with the untrusted space will prevent an attacker from tampering with user B data. Observed Examples
Potential Mitigations
Detection Methods
Related Attack Patterns
References
Content History
CWE-1209: Failure to Disable Reserved Bits
Presentation Filter:
DescriptionThe reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state. Extended DescriptionReserved bits are labeled as such so they can be allocated for a later purpose. They are not to do anything in the current design. However, designers might want to use these bits to debug or control/configure a future capability to help minimize time to market (TTM). If the logic being controlled by these bits is still enabled in production, an adversary could use the logic to induce unwanted/unsupported behavior in the hardware. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 An adversary may perform writes to reserve space in hopes to change the behavior of the hardware. (bad code) Example Language: Other // Assume an IP has address space 0x0-0x0F for its configuration registers, with the last one labeled reserved (i.e. 0x0F). Therefore inside the Finite State Machine (FSM), the code is as follows:
reg gpio_out = 0; //gpio should remain low for normal operation case (register_address) 4'b1111 : //0x0F begin gpio_out = 1; end In the code above, the GPIO pin should remain low for normal operation. However, it can be asserted by accessing the reserved address space (0x0F). This may be a concern if the GPIO state is being used as an indicator of health (e.g. if asserted the hardware may respond by shutting down or resetting the system which may not be the correct action the system should perform). (informative) reg gpio_out = 0; //gpio should remain low for normal operation
case (register_address) //4'b1111 : //0x0F default: gpio_out = gpio_out; Potential Mitigations
Related Attack Patterns
Content History
CWE-1277: Firmware Not Updateable
Presentation Filter:
DescriptionA product's firmware cannot be updated or patched, leaving weaknesses present with no means of repair and the product vulnerable to attack. Extended DescriptionThe inability to patch the product's firmware means that any weaknesses therein cannot be mitigated through an update. This leaves the system/device open to potential exploitation of the inherent weaknesses. External protective measures and mitigations can be employed to aid in preventing malicious behavior, but the root weakness cannot be corrected. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 A refrigerator has an Internet interface for the official purpose of alerting the manufacturer when that refrigerator detects a fault. Because the device is attached to the Internet, the refrigerator is a target for hackers who may wish to use the device other potentially more nefarious purposes. (bad code) Example Language: Other The refrigerator has no means of patching and is hacked becoming a spewer of email spam. (good code) Example Language: Other The device automatically patches itself and provides considerable more protection against being hacked. Potential Mitigations
NotesMaintenance As of CWE 4.3, CWE-1310 and CWE-1277 are being investigated for potential duplication or overlap, since they are both related to the inability to patch a product due to hardware architecture design choices. Maintenance This entry is still under development and will continue to see updates and content improvements. References
Content History
CWE CATEGORY: General Circuit and Logic Design Concerns
SummaryWeaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL. Membership
Content History
CWE-1270: Generation of Incorrect Security Tokens
Presentation Filter:
DescriptionThe product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect. Extended DescriptionSystems-On-a-Chip (SoC) (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify actions originated from various agents. These actions could be "read", "write", "program", "reset", "fetch", "compute", etc. Security Tokens are generated and assigned to every agent on the SoC that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Token based on its trust level or privileges. Incorrectly generated Security Tokens could result in the same token used for multiple agents or multiple tokens being used for the same agent. This condition could result in a Denial-of-Service (DoS) or the execution of an action that in turn could result in privilege escalation or unintended access. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Consider a system with a register for storing an AES key for encryption or decryption. The key is 128 bits long implemented as a set of four 32-bit registers. The key registers are assets, and register, AES_KEY_ACCESS_POLICY, is defined to provide necessary access controls. The access-policy register defines which agents, using a Security Token, may access the AES-key registers. Each bit in this 32-bit register is used to define a Security Token. There could be a maximum of 32 Security Tokens that are allowed access to the AES-key registers. When set (bit = "1") bit number allows action from an agent whose identity matches that bit number. If Clear (bit = "0") the action is disallowed for the corresponding agent. Let"s assume the system has two agents: a Main-controller and an Aux-controller. The respective Security Tokens are "1" and "2".
An agent with a Security Token "1" has access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers. As per the above access policy, the AES-Key-access policy allows access to the AES-key registers if the security Token is "1". (bad code) Example Language: Other The SoC incorrectly generates Security Token "1" for every agent. In other words, both Main-controller and Aux-controller are assigned Security Token "1". Both agents have access to the AES-key registers. (good code) Example Language: Other The SoC should correctly generate Security Tokens, assigning "1" to the Main-controller and "2" to the Aux-controller Potential Mitigations
Content History
CWE-1313: Hardware Allows Activation of Test or Debug Logic at Runtime
Presentation Filter:
DescriptionDuring runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary. Extended DescriptionAn adversary can take advantage of test or debug logic that is made accessible through the hardware during normal operation to modify the intended behavior of the system. For example, an accessible Test/debug mode may allow read/write access to any system data. Using error injection (a common test/debug feature) during a transmit/receive operation on a bus, data may be modified to produce an unintended message. Similarly, confidentiality could be compromised by such features allowing access to secrets. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Potential Mitigations
Related Attack Patterns Content History
CWE-1276: Hardware Child Block Incorrectly Connected to Parent System
Presentation Filter:
DescriptionSignals between a hardware IP and the parent system design are incorrectly connected causing security risks. Extended DescriptionIndividual hardware IP must communicate with the parent system in order for the product to function correctly and as intended. If implemented incorrectly, while not causing any apparent functional issues, may cause security issues. For example, if the IP should only be reset by a system-wide hard reset, but instead the reset input is connected to a software-triggered debug mode reset (which is also asserted during a hard reset), integrity of data inside the IP can be violated. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Many SoCs use hardware to partition system resources between trusted and un-trusted entities. One example of this concept is the Arm TrustZone, in which the processor and all security-aware IP attempt to isolate resources based on the status of a privilege bit. This privilege bit is part of the input interface in all TrustZone-aware IP. If this privilege bit is accidentally grounded or left unconnected when the IP is instantiated, privilege escalation of all input data may occur. (bad code) Example Language: Verilog // IP definition module tz_peripheral(clk, reset, data_in, data_in_security_level, ...); input clk, reset; input [31:0] data_in; input data_in_security_level; ... endmodule // Instantiation of IP in a parent system module soc(...) ... tz_peripheral u_tz_peripheral( .clk(clk), .rst(rst), .data_in(rdata), //Copy-and-paste error or typo grounds data_in_security_level (in this example 0=secure, 1=non-secure) effectively promoting all data to “secure”) .data_in_security_level(1'b0), ); ... endmodule In the Verilog code below, the security level input to the TrustZone aware peripheral is correctly driven by an appropriate signal instead of being grounded. (good code) Example Language: Verilog // Instantiation of IP in a parent system module soc(...) ... tz_peripheral u_tz_peripheral( .clk(clk), .rst(rst), .data_in(rdata), // This port is no longer grounded, but instead drive by the appropriate signal .data_in_security_level(rdata_security_level), ); ... endmodule Potential Mitigations
Content History
CWE-1256: Hardware Features Enable Physical Attacks from Software
Presentation Filter:
DescriptionSoftware-controllable device functionality such as power and clock management permits unauthorized modification of memory or register bits. Extended DescriptionFault injection attacks involve strategic manipulation of bits in a device to achieve a desired effect such as skipping an authentication step, elevating privileges, or altering the output of a cryptographic operation. Techniques employed to flip bits include low-cost methods such as manipulation of the device clock and voltage supply as well as high-cost but more precise techniques involving lasers. To inject faults a physical access requirement is frequently assumed to be necessary. This assumption may be false if the device has improperly secured power management features that allow untrusted programs to manipulate the device clock frequency or operating voltage. For mobile devices, minimizing power consumption is critical, but these devices run a wide variety of applications with different performance requirements. Software-controllable mechanisms to dynamically scale device voltage and frequency are common features in today’s chipsets and can be exploited by attackers if protections are not in place. Other features, such as the ability to write repeatedly to DRAM at a rapid rate from unprivileged software can result in bit flips in other memory locations (Rowhammer). RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Memory IP (Undetermined Prevalence) Power Management IP (Undetermined Prevalence) Clock/Counter IP (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 This example considers the Row-Hammar problem. .The Row-Hammar issue was caulse by a program in a tight loop writing repeatedly to a location to which the program was allowed to write but causing an adjacent memory location value to change. (bad code) Example Language: Other
Continuously writting the same value to the same address causes the value of an adjacent location to change value.
Preventing the loop required to defeat the Row-Hammar exploit is not always possible: (good code) Example Language: Other
Redesign the RAM devices to reduce inter capacitive coupling making the Row-Hammar exploit impossible.
While the redesign may be possible for new devices, a redesign is not possible in existing devices. There is also the possibility that reducing capacitance with a relayout would impact the density of the device resulting in a less capable, more costly device. Example 2 Suppose a hardware design implements a set of software-accessible registers for scaling clock frequency and voltage but does not control access to these registers. Attackers may cause register and memory changes and race conditions by changing the clock or voltage of the device under their control. Observed Examples
Potential Mitigations
Functional Areas
NotesMaintenance This entry is still under development and will continue to see updates and content improvements. The title needs reevaluation. The Extended Description needs evaluation relative to the title and the intent of this hardware entry. The example is not really an example and needs rethought. Related Attack Patterns
References
Content History
CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks
Presentation Filter:
DescriptionSystem configuration protection may be bypassed during debug mode. Extended DescriptionDevice configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set, disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If debug features supported by hardware or internal modes/system states are supported in the hardware design, modification of the lock protection may be allowed allowing access and modification of configuration information. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1
For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1.
(bad code) Example Language: Verilog module Locked_register_example ( input [15:0] Data_in, input Clk, input resetn, input write, input Lock, input scan_mode, input debug_unlocked, output reg [15:0] Data_out ); reg lock_status; always @(posedge Clk or negedge resetn) if (~resetn) // Register is reset resetn begin lock_status <= 1'b0; end else if (Lock) begin lock_status <= 1'b1; end else if (~Lock) begin lock_status <= lock_status end always @(posedge Clk or negedge resetn) if (~resetn) // Register is reset resetn begin Data_out <= 16'h0000; end else if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported for scan_mode & debug_unlocked begin Data_out <= Data_in; end else if (~write) begin Data_out <= Data_out; end endmodule If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock protection may be bypassed. (good code)
Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized users may enable these modes.
Potential Mitigations
Related Attack Patterns Content History
CWE-1298: Hardware Logic Contains Race Conditions
Presentation Filter:
DescriptionA race condition in the hardware logic results in undermining security guarantees of the system. Extended DescriptionA race condition in logic circuits typically occurs when a logic gate gets inputs from signals that have traversed different paths while originating from the same source. Such inputs to the gate can change at slightly different times in response to a change in the source signal. This results in a timing error or a glitch (temporary or permanent) that causes the output to change to an unwanted state before settling back to the desired state. If such timing errors occur in access control logic or finite state machines that are implemented in security sensitive flows, an attacker might exploit them to circumvent existing protections. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Verilog (Undetermined Prevalence) VHDL (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 The code below shows a 2x1 multiplexor using logic gates. Though the code shown below results in the minimum gate solution, it is disjoint and causes glitches. (bad code) Example Language: Verilog
// 2x1 Multiplexor using logic-gates module glitchEx(
input wire in0, in1, sel,
);output wire z wire not_sel; wire and_out1, and_out2; assign not_sel = ~sel; assign and_out1 = not_sel & in0; assign and_out2 = sel & in1; // Buggy line of code: assign z = and_out1 | and_out2; // glitch in signal z endmodule The buggy line of code, commented above, results in signal 'z' periodically changing to an unwanted state. Thus, any logic that references signal 'z' may access it at a time when it is in this unwanted state. This line should be replaced with the line shown below in the Good Code Snippet which results in signal 'z' remaining in a continuous, known, state. Reference for the above code, along with waveforms for simulation can be found in the references below. (good code) Example Language: Verilog
assign z <= and_out1 or and_out2 or (in0 and in1);
This line of code removes the glitch in signal z. Potential Mitigations
References
Content History
CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels
Presentation Filter:
DescriptionThe hardware logic for error handling and security checks can incorrectly forward data before the security check is complete. Extended DescriptionMany high-performance on-chip bus protocols and processor data-paths employ separate channels for control and data to increase parallelism and maximize throughput. Bugs in the hardware logic that handle errors and security checks can make it possible for data to be forwarded before the completion of the security checks. If the data can propagate to a location in the hardware observable to an attacker, loss of data confidentiality can occur. 'Meltdown' is a concrete example of how de-synchronization between data and permissions checking logic can violate confidentiality requirements. Data loaded from a page marked as privileged was returned to the cpu regardless of current privilege level for performance reasons. The assumption was that the cpu could later remove all traces of this data during the handling of the illegal memory access exception, but this assumption was proven false as traces of the secret data were not removed from the microarchitectural state. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 There are several standard on-chip bus protocols used in modern SoCs to allow communication between components. There are a wide variety of commercially available hardware IP implementing the interconnect logic for these protocols. A bus connects components which initiate/request communications such as processors and DMA controllers (bus masters) with peripherals which respond to requests. In a typical system, the privilege level or security designation of the bus master along with the intended functionality of each peripheral determine the security policy specifying which specific bus masters can access specific peripherals. This security policy (commonly referred to as a bus firewall) can be enforced using separate IP/logic from the actual interconnect responsible for the data routing. (bad code) Example Language: Other The firewall and data routing logic becomes de-synchronized due to a hardware logic bug allowing components that should not be allowed to communicate to share data. For example, consider an SoC with two processors. One is being used as a root of trust and can access a cryptographic key storage peripheral. The other processor (application cpu) may run potentially untrusted code and should not access the key store. If the application cpu can issue a read request to the key store which is not blocked due to de-synchronization of data routing and the bus firewall, disclosure of cryptographic keys is possible. (good code) Example Language: Other All data is correctly buffered inside the interconnect until the firewall has determined that the endpoint is allowed to receive the data. Observed Examples
Potential Mitigations
Related Attack Patterns
Content History
CWE-1257: Improper Access Control Applied to Mirrored or Aliased Memory Regions
Presentation Filter:
DescriptionAliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region. Extended DescriptionHardware product designs often need to implement memory protection features that enable privileged software to define isolated memory regions and access control (read/write) policies. Isolated memory regions can be defined on different memory spaces in a design (e.g. system physical address, virtual address, memory mapped IO). Each memory cell should be mapped and assigned a system address that the core software can use to read/write to that memory. It is possible to map the same memory cell to multiple system addresses such that read/write to any of the aliased system addresses would be decoded to the same memory cell. This is commonly done in hardware designs for redundancy and simplifying address decoding logic. If one of the memory regions is corrupted or faulty, then that hardware can switch to using the data in the mirrored memory region. Memory aliases can also be created in the system address map if the address decoder unit ignores higher order address bits when mapping a smaller address region into the full system address. A common security weakness that can exist in such memory mapping is that aliased memory regions could have different read/write access protections enforced by the hardware such that an untrusted agent is blocked from accessing a memory address but is not blocked from accessing the corresponding aliased memory address. Such inconsistency can then be used to bypass the access protection of the primary memory block and read or modify the protected memory. An untrusted agent could also possibly create memory aliases in the system address map for malicious purposes if it is able to change the mapping of an address region or modify memory region sizes. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Memory IP (Undetermined Prevalence) Processor IP (Undetermined Prevalence) Microcontroller IP (Undetermined Prevalence) Network on Chip IP (Undetermined Prevalence) Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1
In a System-on-a-Chip (SoC) design the system fabric uses 16 bit addresses. An IP unit (Unit_A) has 4 kilobyte of internal memory which is mapped into a 16 kilobyte address range in the system fabric address map.
To protect the register controls in Unit_A unprivileged software is blocked from accessing addresses between 0x0000 – 0x0FFF. The address decoder of Unit_A masks off the higher order address bits and decodes only the lower 12 bits for computing the offset into the 4 kilobyte internal memory space. (bad code) Example Language: Other In this design the aliased memory address ranges are these: 0x0000 – 0x0FFF 0x1000 – 0x1FFF 0x2000 – 0x2FFF 0x3000 – 0x3FFF The same register can be accessed using four different addresses: 0x0000, 0x1000, 0x2000, 0x3000. The system address filter only blocks access to range 0x0000 - 0x0FFF and does not block access to the aliased addresses in 0x1000 - 0x3FFF range. Thus, untrusted software can leverage the aliased memory addresses to bypass the memory protection. (good code) Example Language: Other In this design the aliased memory addresses (0x1000 - 0x3FFF) could be blocked from all system software access since they are not used by software. Alternately, the MPU logic can be changed to apply the memory protection policies to the full address range mapped to Unit_A (0x0000 - 0x3FFF). Potential Mitigations
Related Attack Patterns Content History
CWE-1244: Improper Access to Sensitive Information Using Debug and Test Interfaces
Presentation Filter:
DescriptionThe product's physical debug and test interface protection does not block untrusted agents, resulting in unauthorized access to and potentially control of sensitive assets. Extended DescriptionIf the product implements access-control protection on the debug and test interface, a debugger is typically required to enter either a valid response to a challenge provided by the authorization logic or, alternatively, enter the right password in order to exercise the debug and test interface. However, if this protection mechanism does not exclude all untrusted, debug agents, an attacker could access/control security-sensitive registers. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 The JTAG interface is used to perform debugging and provide CPU core access for developers. JTAG-access protection is implemented as part of the JTAG_SHIELD bit in the hw_digctl_ctrl register. This register has no default value at power up and is set only after the system boots from ROM and control is transferred to the user software. (bad code) Example Language: Other
This means that as the end user has access to JTAG at system reset and during ROM code execution before control is transferred to user software, a JTAG user can modify the boot flow and subsequently disclose all CPU information including data-encryption keys. (informative) The default value of this register bit should be set to 1 to prevent the JTAG from being enabled at system reset.
Observed Examples
Potential Mitigations
Notes Related Attack Patterns References
Content History
CWE-1245: Improper Finite State Machines (FSMs) in Hardware Logic
Presentation Filter:
DescriptionFaulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system. Extended DescriptionThe functionality and security of the system heavily depend on the implementation of FSMs. FSMs can be used to indicate the current security state of the system. Lots of secure data operations and data transfers rely on the state reported by the FSM. Faulty FSM designs that do not account for all states, either through undefined states (left as don't cares) or through incorrect implementation, might lead an attacker to drive the system into an unstable state from which the system cannot recover without a reset, thus causing a DoS. Depending on what the FSM is used for, an attacker might also gain additional privileges to launch further attacks and compromise the security guarantees. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 The FSM shown in the "bad" code snippet below assigns the output out based on the value of state, which is determined based on the user provided input, user_input. (bad code) Example Language: Verilog module fsm_1(out, user_input, clk, rst_n);
input [2:0] user_input; input clk, rst_n; output reg [2:0] out; reg [1:0] state; always @ (posedge clk or negedge rst_n ) begin
if (!rst_n)
state = 3'h0; else case (user_input) 3'h0: 3'h1: 3'h2: 3'h3: state = 2'h3; 3'h4: state = 2'h2; 3'h5: state = 2'h1; endcase end out <= {1'h1, state}; endmodule
The case statement does not handle the scenario when user provides inputs of 3'h6 and 3'h7 using a default statement. Those inputs push the system to an undefined state and might cause a crash (denial of service) or any other unanticipated outcome. Adding a default statement to handle undefined inputs mitigates this issue. This is shown in the "Good" code snippet below. The default statement is in bold. (good code) Example Language: Other case (user_input)
3'h0:
3'h1: 3'h2: 3'h3: state = 2'h3; 3'h4: state = 2'h2; 3'h5: state = 2'h1; default: state = 2'h0; endcase Potential Mitigations
Related Attack Patterns
References
Content History
CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges
Presentation Filter:
DescriptionThe product allows address regions to overlap, which can result in the bypassing of intended memory protection. Extended DescriptionIsolated memory regions and access control (read/write) policies are used by hardware to protect privileged software. Software components are often allowed to change or remap memory region definitions in order to enable flexible and dynamically changeable memory management by system software. If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege, privilege escalation may be available to attackers. The memory protection unit (MPU) logic can incorrectly handle such an address overlap and allow the lower privilege software to read or write into the protected memory region resulting in privilege escalation attack. Address overlap weakness can also be used to launch a denial of service attack on the higher privilege software memory regions. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Memory IP (Undetermined Prevalence) Processor IP (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1
For example, consider a design with a 16-bit address that has two software privilege levels: Privilege_SW and Non_privilege_SW. To isolate the system memory regions accessible by these two privilege levels, the design supports three memory regions: Region_0, Region_1, Region_2.
Each region range is defined by two 32 bit registers Address_range and Access_policy:
The address-protection filter checks the address range and access policies of all three regions and only allows software access if all three filters allow access. (bad code) In this design example, Non_privilege_SW cannot modify memory region and policies defined by Privilege_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privilege_SW is using. However, Non_privilege_SW can program Region_2 registers to overlap with Region_0 or Region_1, and it can also define the access policy of Region_2. Using this capability, it is possible for Non_privilege_SW to block any memory region from being accessed by Privilege_SW, including the memory regions protected by Region_0 and Region_1. (good code) In such a design, a memory region priority should be defined to ensure that the memory region defined by Non_privilege_SW in Region_2 cannot change the access policy defined in Region_0 or Region_1. Observed Examples
Potential Mitigations
Notes Related Attack Patterns
References
Content History
CWE-1261: Improper Handling of Single Event Upsets
Presentation Filter:
DescriptionThe hardware logic does not effectively handle when single-event upsets (SEUs) occur. Extended DescriptionTechnology trends such as CMOS-transistor down-sizing, use of new materials, and system-on-chip architectures continue to increase the sensitivity of systems to soft errors. These errors are random, and their causes might be internal (e.g., interconnect coupling) or external (e.g., cosmic radiation). These soft errors are not permanent in nature and cause temporary bit flips known as single-event upsets (SEUs). SEUs are induced errors in circuits caused when charged particles lose energy by ionizing the medium through which they pass, leaving behind a wake of electron-hole pairs that cause temporary failures. If these failures occur in security-sensitive modules in a chip, it might compromise the security guarantees of the chip. For instance, these temporary failures could be bit flips that change the privilege of a regular user to root. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 This is an example from [REF-1089]. See the reference for full details of this issue. Parity is error detecting but not error correcting. (bad code) Example Language: Other Due to single-event upsets, bits are flipped in memories. As a result, memory-parity checks fail, which results in restart and a temporary denial of service of two to three minutes. (good code) Example Language: Other Using error-correcting codes could have avoided the restart caused by SEUs. Example 2 In 2016, a security researcher, who was also a patient using a pacemaker, was on an airplane when a bit flip occurred in the pacemaker, likely due to the higher prevalence of cosmic radiation at such heights. The pacemaker was designed to account for bit flips and went into a default safe mode, which still forced the patient to go to a hospital to get it reset. The bit flip also inadvertently enabled the researcher to access the crash file, perform reverse engineering, and detect a hard-coded key. [REF-1101] Potential Mitigations
References
Content History
CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls
Presentation Filter:
DescriptionThe product implements a register lock bit protection feature that permits security sensitive controls to modify the protected configuration. Extended DescriptionIntegrated circuits and hardware IPs can expose the device configuration controls that need to be programmed after device power reset by a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If any system registers/controls that can modify the protected configuration are not write-protected by the lock, they can then be leveraged by software to modify the protected configuration. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 For example, consider the example design below or a digital thermal sensor used in the design to detect overheating of the silicon to trigger a system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by the firmware. (bad code) Example Language: Other
In this example note that only the CRITICAL_TEMP_LIMIT register is protected by the TEMP_SENSOR_LOCK bit, while the security design intent is to protect any modification of the critical temperature detection and response. The response of the system, if the system heats to a critical temperature, is controlled by TEMP_HW_SHUTDOWN bit [1], which is not lockable. Also, the TEMP_SENSOR_CALIB register is not protected by the lock bit. By modifying the temperature sensor calibration, the conversion of the sensor data to a degree centigrade can be changed, such that the current temperature will never be detected to exceed critical temperature value programmed by the protected lock. Similarly, by modifying the TEMP_HW_SHUTDOWN.Enable bit, the system response detection of the current temperature exceeding critical temperature can be disabled. (informative) Change TEMP_HW_SHUTDOWN and TEMP_SENSOR_CALIB controls to be locked by TEMP_SENSOR_LOCK.
Potential Mitigations
Notes Related Attack Patterns Content History
CWE-1231: Improper Implementation of Lock Protection Registers
Presentation Filter:
DescriptionThe product incorrectly implements register lock bit protection features such that protected controls can be programmed even after the lock has been set. Extended DescriptionIn integrated circuits and hardware IPs, device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set disables writes to a protected set of registers or address regions. Design or coding errors in the implementation of the lock bit protection feature may allow the lock bit to be modified or cleared by software after being set to unlock the system. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Consider the example design below or a digital thermal sensor used in the design to detect overheating of the silicon and trigger system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by firmware and then the register needs to be locked (TEMP_SENSOR_LOCK). (bad code) Example Language: Other
In this example note that the response of the system if the system heats to critical temperature is controlled by TEMP_HW_SHUTDOWN bit [1], which is not lockable. Thus, the intended security property of the critical temperature sensor cannot be fully protected,since software can misconfigure the TEMP_HW_SHUTDOWN register even after the lock bit is set to disable the shutdown response. (mitigation) Change TEMP_HW_SHUTDOWN field to be locked by TEMP_SENSOR_LOCK.
Potential Mitigations
Related Attack Patterns
Content History
CWE-1331: Improper Isolation of Shared Resources in Network On Chip
Presentation Filter:
DescriptionThe product does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels. Extended DescriptionTypically, network on chips (NoC) have many internal resources that are shared between packets from different, trust domains. These resources include internal buffers, crossbars and switches, individual ports, and channels. The sharing of resources causes contention and introduces interference between differently trusted domains, which poses a security threat via a timing channel allowing attackers to infer data that belongs to a trusted agent. This may also result in introducing network interference resulting in degraded throughput and latency. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Security IP (Undetermined Prevalence) Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Consider a NoC that implements a one-dimensional, mesh network with four nodes. This supports two flows: Flow A from node 0 to node 3 (via node 1 and node 2) and Flow B from node 1 to node 2. Flows A and B share a common link between Node 1 and Node 2. Only one flow can use the link in each cycle. One of the masters to this NoC implements a crypto algorithm (RSA), and another master to the NoC is a core that can be exercised by an attacker. The RSA algorithm performs a modulo multiplication of two, large numbers and depends on each bit of the secret key. The algorithm examines each bit in the secret key and only performs multiplication if the bit is 1. This algorithm is known to be prone to timing attacks. Whenever RSA performs multiplication, there is additional, network traffic to the memory controller. One of the reasons for this is cache conflicts. Since this is a one-dimensional mesh, only one flow can use the link in each cycle. Also, packets from the attack program and the RSA program share the output port of the network-on-chip. This contention results in network interference, and the throughput and latency of one flow can be affected by the other flow’s demand. The attacker runs a loop program on the core they control, and this causes a cache miss in every iteration for the RSA algorithm. Thus, by observing network-traffic bandwidth and timing, the attack program can determine when the RSA algorithm is doing a multiply operation (i.e., when secret key bit is 1) and eventually extract the entire, secret key. Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents. Potential Mitigations
Related Attack Patterns
References
Content History
CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
Presentation Filter:
DescriptionThe product does not properly isolate shared resources between trusted and untrusted agents. Extended DescriptionA System-On-a-Chip (SoC) has a lot of functionality, but may have a limited number of pins or pads. A pin can only perform one function at a time. However, it can be configured to perform multiple different functions. This technique is called pin multiplexing. Similarly, several resources on the chip may be shared to multiplex and support different features or functions. When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access the assets intended to be accessed only by the trusted agents. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Potential Mitigations
Detection Methods
Related Attack Patterns
References
Content History
CWE-1232: Improper Lock Behavior After Power State Transition
Presentation Filter:
DescriptionRegister lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable. Extended DescriptionDevices may allow device configuration controls which need to be programmed after device power reset via a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. This action is commonly implemented using a programmable lock bit, which, when set, disables writes to a protected set of registers or address regions. After a power state transition, the lock bit is set to unlocked. Some common weaknesses that can exist in such a protection scheme are that the lock gets cleared, the values of the protected registers get reset, or the lock become programmable. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1
Consider the memory configuration settings of a system that uses DDR3 DRAM memory. Protecting the DRAM memory configuration from modification by software is required to ensure that system memory access control protections cannot be bypassed. This can be done by using lock bit protection that locks all of the memory configuration registers. The memory configuration lock can be set by the BIOS during the boot process. If such a system also supports a rapid power on mode like hibernate, the DRAM data must be saved to a disk before power is removed and restored back to the DRAM once the system powers back up and before the OS resumes operation after returning from hibernate. To support the hibernate transition back to the operating state, the DRAM memory configuration must be reprogrammed even though it was locked previously. As the hibernate resume does a partial reboot, the memory configuration could be altered before the memory lock is set. Functionally the hibernate resume flow requires a bypass of the lock-based protection. The memory configuration must be securely stored and restored by trusted system firmware. Lock settings and system configuration must be restored to the same state it was in before the device entered into the hibernate mode. Potential Mitigations
Related Attack Patterns
Content History
CWE-1323: Improper Management of Sensitive Trace Data
Presentation Filter:
DescriptionTrace data collected from several sources on the System-on-Chip (SoC) is stored in unprotected locations or transported to untrusted agents. Extended DescriptionTo facilitate verification of complex System-on-Chip (SoC) designs, SoC integrators add specific IP blocks that trace the SoC's internal signals in real-time. This infrastructure enables observability of the SoC's internal behavior, validation of its functional design, and detection of hardware and software bugs. Such tracing IP blocks collect traces from several sources on the SoC including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then aggregated inside trace IP block and forwarded to trace sinks, such as debug-trace ports that facilitate debugging by external hardware and software debuggers. Since these traces are collected from several security-sensitive sources, they must be protected against untrusted debuggers. If they are stored in unprotected memory, an untrusted software debugger can access these traces and extract secret information. Additionally, if security-sensitive traces are not tagged as secure, an untrusted hardware debugger might access them to extract confidential information. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 In a SoC, traces generated from sources include security-sensitive IP blocks such as CPU (with tracing information such as instructions executed and memory operands), on-chip fabric (e.g., memory-transfer signals, transaction type and destination, and on-chip-firewall-error signals), power-management IP blocks (e.g., clock- and power-gating signals), and cryptographic coprocessors (e.g., cryptographic keys and intermediate values of crypto operations), among other non-security-sensitive IP blocks including timers and other functional blocks. The collected traces are then forwarded to the debug and trace interface used by the external hardware debugger. (bad code) Example Language: Other The traces do
not have any privilege level attached to them. All
collected traces can be viewed by any debugger (i.e., SoC
designer, OEM debugger, or end user). (good code) Example Language: Other Some of the
traces are SoC-design-house secrets, while some are OEM
secrets. Few are end-user secrets and the rest are
not security-sensitive. Tag all traces with the
appropriate, privilege level at the source. The bits
indicating the privilege level must be immutable in
their transit from trace source to the final, trace
sink. Debugger privilege level must be checked before
providing access to traces. Potential Mitigations
Related Attack Patterns References
Content History
CWE-1263: Improper Physical Access Control
Presentation Filter:
DescriptionThe product is to be designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor's ability to access these areas. Extended DescriptionSections of a product intended to have restricted access may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Potential Mitigations
NotesMaintenance This entry is still under development and will continue to see updates and content improvements. Related Attack Patterns
Content History
CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI)
Presentation Filter:
DescriptionThe device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed. Extended DescriptionElectromagnetic fault injection may allow an attacker to locally and dynamically modify the signals (both internal and external) of an integrated circuit. EM-FI attacks consist of producing a local, transient magnetic field near the device, inducing current in the device wires. A typical EMFI setup is made up of a pulse injection circuit that generates a high current transient in an EMI coil, producing an abrupt magnetic pulse which couples to the target producing faults in the device, which can lead to:
RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Microcontroller IP (Undetermined Prevalence) Memory IP (Undetermined Prevalence) Power Management IP (Undetermined Prevalence) Processor IP (Undetermined Prevalence) Test/Debug IP (Undetermined Prevalence) Sensor IP (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 In many devices, security related information is stored in fuses. These fuses are loaded into shadow registers at boot time. Disturbing this transfer phase with EM-FI can lead to the shadow registers storing erroneous values potentially resulting in reduced security. Colin O'Flynn has demonstrated an attack scenario which uses electro-magnetic glitching during booting to bypass security and gain read access to flash, read and erase access to shadow memory area (where the private password is stored). Most devices in the MPC55xx and MPC56xx series that include the Boot Assist Module (BAM) (a serial or CAN bootloader mode) are susceptible to this attack. In this paper, a GM ECU was used as a real life target. While the success rate appears low (less than 2 percent), in practice a success can be found within 1-5 minutes once the EMFI tool is setup. In a practical scenario, the author showed that success can be achieved within 30-60 minutes from a cold start. Potential Mitigations
NotesMaintenance This entry is attack-oriented and may require significant modification in future versions, or even deprecation. It is not clear whether there is really a design "mistake" that enables such attacks, so this is not necessarily a weakness and may be more appropriate for CAPEC. Related Attack Patterns
References
Content History
CWE-1300: Improper Protection Against Physical Side Channels
Presentation Filter:
DescriptionThe product is missing protections or implements insufficient protections against information leakage through physical channels such as power consumption, electromagnetic emissions (EME), acoustic emissions, or other physical attributes. Extended DescriptionPhysical properties of the hardware implementation such as power consumption or EME can result in data disclosure even if it is not possible to extract the information in the digital domain. Physical side channels such as power consumption, electromagnetic emissions (EME), and acoustic emissions have been well-studied for decades in the context of breaking implementations of cryptographic algorithms. These side-channels may be easily observed by an attacker with physical access to the device. Power, EME, and acoustic measurements obtained during hardware operation are correlated to data processed by the hardware, enabling recovery of secret keys and data. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Potential Mitigations
Functional Areas
NotesMaintenance This entry is still under development and will continue to see updates and content improvements. Maintenance References
Content History
CWE-1320: Improper Protection for Out of Bounds Signal Level Alerts
Presentation Filter:
DescriptionUntrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts. Extended DescriptionHardware sensors are used to detect whether a device is operating within design limits. The threshold values for these limits are set by hardware fuses or trusted software such as a BIOS. Modification of these limits may be protected by hardware mechanisms. When device sensors detect out of bound conditions, alert signals may be generated for remedial action, which may take the form of device shutdown or throttling. Warning signals that are not properly secured may be disabled or used to generate spurious alerts, causing degraded performance or denial-of-service (DoS). These alerts may be masked by untrusted software. Examples of these alerts involve thermal and power sensor alerts. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Microcontroller IP (Undetermined Prevalence) Memory IP (Undetermined Prevalence) Power Management IP (Undetermined Prevalence) Processor IP (Undetermined Prevalence) Test/Debug IP (Undetermined Prevalence) Sensor IP (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1
Consider a platform design where a Digital-Thermal Sensor (DTS) is used to monitor temperature and compare that output against a threshold value. If the temperature output equals or exceeds the threshold value, the DTS unit sends an alert signal to the processor. The processor, upon getting the alert, input triggers system shutdown. The alert signal is handled as a General-Purpose-I/O (GPIO) pin in input mode. (bad code) The processor-GPIO controller exposes software-programmable controls that allow untrusted software to reprogram the state of the GPIO pin. Reprogramming the state of the GPIO pin allows malicious software to trigger spurious alerts or to set the alert pin to a zero value so that thermal sensor alerts are not received by the processor. (good code) The GPIO alert-signal pin is blocked from untrusted software access and is controlled only by trusted software, such as the System BIOS. Potential Mitigations
Related Attack Patterns Content History
CWE-1338: Improper Protections Against Hardware Overheating
Presentation Filter:
DescriptionA hardware device is missing or has inadequate protection features to prevent overheating. Extended DescriptionHardware, electrical circuits, and semiconductor silicon have thermal side effects, such that some of the energy consumed by the device gets dissipated as heat and increases the temperature of the device. For example, in semiconductors, higher-operating frequency of silicon results in higher power dissipation and heat. The leakage current in CMOS circuits increases with temperature, and this creates positive feedback that can result in thermal runaway and damage the device permanently. Any device lacking protections such as thermal sensors, adequate platform cooling or thermal insulation is susceptible to attacks by malicious software that might deliberately operate the device in modes that result in overheating. This can be used as an effective denial of service (DoS) or permanent denial of service (PDoS) attack. Depending on the type of hardware device and its expected usage, such thermal overheating can also cause safety hazards and reliability issues. Note that battery failures can also cause device overheating but the mitigations and examples included in this submission cannot reliably protect against a battery failure. There can be similar weaknesses with lack of protection from attacks based on overvoltage or overcurrent conditions. However, thermal heat is generated by hardware operation and the device should implement protection from overheating. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Power Management IP (Undetermined Prevalence) Processor IP (Undetermined Prevalence) Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Malicious software running on a core can execute instructions that consume maximum power or increase core frequency. Such a power-virus program could execute on the platform for an extended time to overheat the device, resulting in permanent damage. Execution core and platform do not support thermal sensors, performance throttling, or platform-cooling countermeasures to ensure that any software executing on the system cannot cause overheating past the maximum allowable temperature. The platform and SoC should have failsafe thermal limits that are enforced by thermal sensors that trigger critical temperature alerts when high temperature is detected. Upon detection of high temperatures, the platform should trigger cooling or shutdown automatically. Potential Mitigations
Detection Methods
References
Content History
CWE-1259: Improper Restriction of Security Token Assignment
Presentation Filter:
DescriptionThe 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. Extended DescriptionSystems-On-A-Chip (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify which actions originated from which agent. These actions may be one of the directives: 'read', 'write', 'program', 'reset', 'fetch', 'compute', etc. Security Tokens are assigned to every agent in the System that is capable of generating an action or receiving an action from another agent. Multiple Security Tokens may be assigned to an agent and may be unique based on the agent's trust level or allowed privileges. Since the Security Tokens are integral for the maintanence of security in an SoC, they need to be protected properly. A common weakness afflicting Security Tokens is improperly restricting the assignment to trusted components. Consequently, an improperly protected Security Token may be able to be programmed by a malicious agent (i.e., the Security Token is mutable) to spoof the action as if it originated from a trusted agent. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Processor IP Class: Technology-Independent (Undetermined Prevalence) Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 For example, consider a system with a register for storing an AES key for encryption and decryption. The key is of 128 bits implemented as a set of four 32-bit registers. The key register assets have an associated control register, AES_KEY_ACCESS_POLICY, which provides the necessary access controls. This access-policy register defines which agents may engage in a transaction, and the type of transaction, with the AES-key registers. Each bit in this 32-bit register defines a security Token. There could be a maximum of 32 security Tokens that are allowed access to the AES-key registers. The number of the bit when set (i.e., “1”) allows respective action from an agent whose identity matches the number of the bit and, if “0” (i.e., Clear), disallows the respective action to that corresponding agent. Let’s assume the system has two agents: a Main-controller and an Aux-controller. The respective Security Tokens are “1” and “2”.
An agent with Security Token “1” has access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers. As per the above access policy, the AES-Key-access policy allows access to the AES-key registers if the security Token is “1”. (bad code) Example Language: Other The Aux-controller could program its Security Token to “1” from “2”. The SoC does not properly protect the Security Token of the agents, and, hence, the Aux-controller in the above example can spoof the transaction (i.e., send the transaction as if it is coming from the Main-controller to access the AES-Key registers) (good code) Example Language: Other The SoC needs to protect the Security Tokens. None of the agents in the SoC should have the ability to change the Security Token. Potential Mitigations
NotesMaintenance
This entry is still under development and will continue to see updates and content improvements. Currently it is expressed as a general absence of a protection mechanism as opposed to a specific mistake, and the entry's name and description could be interpreted as applying to software.
Related Attack Patterns
Content History
CWE-1224: Improper Restriction of Write-Once Bit Fields
Presentation Filter:
DescriptionThe hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software. Extended DescriptionIntegrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to define default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make the settings write-once or "sticky." This allows writing to such registers only once, whereupon they become read-only. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. Failure to implement write-once restrictions in hardware design can expose such registers to being re-programmed by software and written multiple times. For example, write-once fields could be implemented to only be write-protected if they have been set to value "1", wherein they would work as "write-1-once" and not "write-once". RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Verilog (Undetermined Prevalence) VHDL (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 Consider the example design module system verilog code shown below. register_write_once_example module is an example of register that has a write-once field defined. Bit 0 field captures the write_once_status value. This implementation can be for a register that is defined by specification to be a write-once register, since the write_once_status field gets written by input data bit 0 on first write. (bad code) Example Language: Verilog module register_write_once_example
( input [15:0] Data_in, input Clk, input ip_resetn, input global_resetn, input write, output reg [15:0] Data_out ); reg Write_once_status; always @(posedge Clk or negedge ip_resetn) if (~ip_resetn) begin Data_out <= 16'h0000; Write_once_status <= 1'b0; end else if (write & ~Write_once_status) begin Data_out <= Data_in & 16'hFFFE; Write_once_status <= Data_in[0]; // Input bit 0 sets Write_once_status end else if (~write) begin Data_out[15:1] <= Data_out[15:1]; Data_out[0] <= Write_once_status; end endmodule The above example only locks further writes if write_once_status bit is written to one. So it acts as write_1-Once instead of the write-once attribute. (informative) module register_write_once_example
( input [15:0] Data_in, input Clk, input ip_resetn, input global_resetn, input write, output reg [15:0] Data_out ); reg Write_once_status; always @(posedge Clk or negedge ip_resetn) if (~ip_resetn) begin Data_out <= 16'h0000; Write_once_status <= 1'b0; end else if (write & ~Write_once_status) begin Data_out <= Data_in & 16'hFFFE; Write_once_status <= 1'b1; // Write once status set on first write, independent of input end else if (~write) begin Data_out[15:1] <= Data_out[15:1]; Data_out[0] <= Write_once_status; end endmodule Potential Mitigations
Related Attack Patterns Content History
CWE-1266: Improper Scrubbing of Sensitive Data from Decommissioned Device
Presentation Filter:
DescriptionThe 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. Extended DescriptionWhen a product is decommissioned - i.e., taken out of service - best practices or regulatory requirements may require the administrator to remove or overwrite sensitive data first, i.e. "scrubbing." Improper scrubbing of sensitive data from a decommissioned device leaves that data vulnerable to acquisition by a malicious actor. Sensitive data may include, but is not limited to, device/manufacturer proprietary information, user/device credentials, network configurations, and other forms of sensitive data. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Potential Mitigations
NotesMaintenance This entry is still under development and will continue to see updates and content improvements. Related Attack Patterns References
Content History
CWE-1315: Improper Setting of Bus Controlling Capability in Fabric End-point
Presentation Filter:
DescriptionThe bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric. Extended DescriptionTo support reusability, certain fabric interfaces and end points provide a configurable register bit that allows IP blocks connected to the controller to access other peripherals connected to the fabric. This allows the end point to be used with devices that function as a controller or responder. If this bit is set by default in hardware, or if firmware incorrectly sets it later, a device intended to be a responder on a fabric is now capable of controlling transactions to other devices and might compromise system security. RelationshipsThe table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Hardware Design" (CWE-1194)
Modes Of IntroductionThe 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.
Applicable PlatformsThe listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: Technology-Independent (Undetermined Prevalence) Common ConsequencesThe table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Demonstrative ExamplesExample 1 A typical, phone platform consists of the main, compute core or CPU, a DRAM-memory chip, an audio codec, a baseband modem, a power-management-integrated circuit (“PMIC”), a connectivity (WiFi and Bluetooth) modem, and several other analog/RF components. The main CPU is the only component that can control transactions, and all the other components are responder-only devices. All the components implement a PCIe end-point to interface with the rest of the platform. The responder devices should have the bus-control-enable bit in the PCIe-end-point register set to 0 in hardware to prevent the devices from controlling transactions to the CPU or other peripherals. The audio-codec chip does not have the bus-controller-enable-register bit hardcoded to 0. There is no platform-firmware flow to verify that the bus-controller-enable bit is set to 0 in all responders. Audio codec can now master transactions to the CPU and other platform components. Potentially, it can modify assets in other platform components to subvert system security. Platform firmware includes a flow to check the configuration of bus-controller-enable bit in all responder devices. If this register bit is set on any of the responders, platform firmware sets it to 0. Ideally, the default value of this register bit should be hardcoded to 0 in RTL. It should also have access control to prevent untrusted entities from setting this bit to become bus controllers. Potential Mitigations
Notes | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
