CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-1194: Hardware Design (4.1)  
ID

CWE VIEW: Hardware Design

View ID: 1194
Type: Graph
Status: Incomplete
Downloads: Booklet | CSV | XML
+ Objective
This view organizes weaknesses around concepts that are frequently used or encountered in hardware design. Accordingly, this view can align closely with the perspectives of designers, manufacturers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.
+ Audience
StakeholderDescription
Hardware DesignersHardware Designers use this view to better understand potential mistakes that can be made in specific areas of their IP design. The use of concepts with which hardware designers are familiar makes it easier to navigate.
EducatorsEducators use this view to teach future professionals about the types of mistakes that are commonly made in hardware design.
+ Relationships
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
1194 - Hardware Design
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Manufacturing and Life Cycle Management Concerns - (1195)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns)
Weaknesses in this category are root-caused to defects that arise in the semiconductor-manufacturing process or during the life cycle and supply chain.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Semiconductor Defects in Hardware Logic with Security-Sensitive Implications - (1248)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1248 (Semiconductor Defects in Hardware Logic with Security-Sensitive Implications)
The security-sensitive hardware module contains semiconductor defects.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Scrubbing of Sensitive Data from Decommissioned Device - (1266)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1266 (Improper Scrubbing of Sensitive Data from Decommissioned Device)
The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned. A scrubbing capability could be missing, insufficient, or incorrect.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Product Released in Non-Release Configuration - (1269)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1269 (Product Released in Non-Release Configuration)
The product released to market is released in pre-production or manufacturing configuration.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Device Unlock Credential Sharing - (1273)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1273 (Device Unlock Credential Sharing)
The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)
1194 (Hardware Design) > 1195 (Manufacturing and Life Cycle Management Concerns) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Secrets stored in hardware can be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Security Flow Issues - (1196)
1194 (Hardware Design) > 1196 (Security Flow Issues)
Weaknesses in this category are related to improper design of full-system security flows, including but not limited to secure boot, secure update, and hardware-device attestation.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.DMA Device Enabled Too Early in Boot Phase - (1190)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1190 (DMA Device Enabled Too Early in Boot Phase)
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Power-On of Untrusted Execution Core Before Enabling Fabric Access Control - (1193)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1193 (Power-On of Untrusted Execution Core Before Enabling Fabric Access Control)
The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Hardware Logic with Insecure De-Synchronization between Control and Data Channels - (1264)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1264 (Hardware Logic with Insecure De-Synchronization between Control and Data Channels)
The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.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.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Mutable Attestation or Measurement Reporting Data - (1283)
1194 (Hardware Design) > 1196 (Security Flow Issues) > 1283 (Mutable Attestation or Measurement Reporting Data)
The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Integration Issues - (1197)
1194 (Hardware Design) > 1197 (Integration Issues)
Weaknesses in this category are those that arise due to integration of multiple hardware Intellectual Property (IP) cores from third parties, or from the prior generation of products into a common System-on-Chip (SoC) or hardware platform.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Hardware Block Incorrectly Connected to Larger System - (1276)
1194 (Hardware Design) > 1197 (Integration Issues) > 1276 (Hardware Block Incorrectly Connected to Larger System)
Signals between a hardware IP and the larger system design are incorrectly connected.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Privilege Separation and Access Control Issues - (1198)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues)
Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Default Permissions - (276)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 276 (Incorrect Default Permissions)
The product, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Isolation of Shared Resources on System-on-Chip (SoC) - (1189)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1189 (Improper Isolation of Shared Resources on System-on-Chip (SoC))
The product does not properly isolate shared resources between trusted and untrusted agents.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers - (1192)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1192 (System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers)
The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Insufficient Granularity of Access Control - (1220)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1220 (Insufficient Granularity of Access Control)
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Inclusion of Undocumented Features or Chicken Bits - (1242)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1242 (Inclusion of Undocumented Features or Chicken Bits)
The chip includes chicken bits or undocumented features that can create entry points for unauthorized actors.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Handling of Overlap Between Protected Memory Ranges - (1260)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1260 (Improper Handling of Overlap Between Protected Memory Ranges)
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.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.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Protection of Security Identifiers - (1259)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1259 (Improper Protection of Security Identifiers)
The product 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 improperly protected.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Policy Uses Obsolete Encoding - (1267)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1267 (Policy Uses Obsolete Encoding)
The product uses an obsolete encoding mechanism to implement access controls.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Agents Included in Control Policy are not Contained in Less-Privileged Policy - (1268)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1268 (Agents Included in Control Policy are not Contained in Less-Privileged Policy)
The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Generation of Incorrect Security Identifiers - (1270)
1194 (Hardware Design) > 1198 (Privilege Separation and Access Control Issues) > 1270 (Generation of Incorrect Security Identifiers)
The product implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers generated in the system are incorrect.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.General Circuit and Logic Design Concerns - (1199)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns)
Weaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Failure to Disable Reserved Bits - (1209)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1209 (Failure to Disable Reserved Bits)
The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design. However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Register Defaults or Module Parameters - (1221)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1221 (Incorrect Register Defaults or Module Parameters)
Hardware description language code incorrectly defines register defaults or hardware IP parameters to insecure values.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Race Condition for Write-Once Attributes - (1223)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1223 (Race Condition for Write-Once Attributes)
A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of Write-Once Bit Fields - (1224)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1224 (Improper Restriction of Write-Once Bit Fields)
The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper 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.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Lock Behavior After Power State Transition - (1232)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1232 (Improper Lock Behavior After Power State Transition)
The product implements register lock bit protection features with the intent to disable changes to system configuration after the lock 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).
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper 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.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Hardware Internal or Debug Modes Allow Override of Locks - (1234)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)
The product implements register lock bit protection features that may permit security sensitive controls to modify system configuration after the lock is set through internal modes or debug features.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Finite State Machines (FSMs) in Hardware Logic - (1245)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1245 (Improper Finite State Machines (FSMs) in Hardware Logic)
Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Selection of Fuse Values - (1253)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1253 (Incorrect Selection of Fuse Values)
The logic used to determine system-security state for the product relies on values sensed from the fuses, but it relies on 'negative' logic for an un-blown fuse.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Comparison Logic Granularity - (1254)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1254 (Incorrect Comparison Logic Granularity)
The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Protection of Security Identifiers - (1259)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1259 (Improper Protection of Security Identifiers)
The product 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 improperly protected.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Handling of Single Event Upsets - (1261)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1261 (Improper Handling of Single Event Upsets)
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Generation of Incorrect Security Identifiers - (1270)
1194 (Hardware Design) > 1199 (General Circuit and Logic Design Concerns) > 1270 (Generation of Incorrect Security Identifiers)
The product implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers generated in the system are incorrect.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Core and Compute Issues - (1201)
1194 (Hardware Design) > 1201 (Core and Compute Issues)
Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations - (1252)
1194 (Hardware Design) > 1201 (Core and Compute Issues) > 1252 (CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations)
The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Sequence of Processor Instructions Leads to Unexpected Behavior (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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Memory and Storage Issues - (1202)
1194 (Hardware Design) > 1202 (Memory and Storage Issues)
Weaknesses in this category are typically associated with memory (e.g., DRAM, SRAM) and storage technologies (e.g., NAND Flash, OTP, EEPROM, and eMMC).
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Sensitive Information Uncleared in Resource Before Release for Reuse - (226)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 226 (Sensitive Information Uncleared in Resource Before Release for Reuse)
The product prepares to release a resource such as memory or a file so that the resource can be reused by other entities, but the product does not fully clear previously-used sensitive information from that resource before the resource is released.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Write Handling in Limited-write Non-Volatile Memories - (1246)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1246 (Improper Write Handling in Limited-write Non-Volatile Memories)
The product does not implement or incorrectly handles the implementation of write operations in limited-write non-volatile memories.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Mirrored Regions with Different Values - (1251)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1251 (Mirrored Regions with Different Values)
The product's architecture mirrors regions without ensuring that their contents always stay in sync.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Access Control Applied to Mirrored or Aliased Memory Regions - (1257)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1257 (Improper Access Control Applied to Mirrored or Aliased Memory Regions)
Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by hardware. In this way, it could be possible that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Assumed-Immutable Data Stored in Writable Memory - (1282)
1194 (Hardware Design) > 1202 (Memory and Storage Issues) > 1282 (Assumed-Immutable Data 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/updated in the field.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Peripherals, On-chip Fabric, and Interface/IO Problems - (1203)
1194 (Hardware Design) > 1203 (Peripherals, On-chip Fabric, and Interface/IO Problems)
Weaknesses in this category are related to hardware security problems that apply to peripheral devices, IO interfaces, on-chip interconnects, network-on-chip (NoC), and buses. For example, this category includes issues related to design of hardware interconnect and/or protocols such as PCIe, USB, SMBUS, general-purpose IO pins, and user-input peripherals such as mouse and keyboard.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Security Primitives and Cryptography Issues - (1205)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues)
Weaknesses in this category are related to hardware implementations of cryptographic protocols and other hardware-security primitives such as physical unclonable functions (PUFs) and random number generators (RNGs).
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Observable Discrepancy - (203)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 203 (Observable Discrepancy)
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.Side Channel Attack
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Required Cryptographic Step - (325)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 325 (Missing Required Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by that algorithm.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of a Risky Cryptographic Primitive - (1240)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1240 (Use of a Risky Cryptographic Primitive)
The product implements a cryptographic algorithm using a non-standard or unproven cryptographic primitive.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Predictable Algorithm in Random Number Generator - (1241)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1241 (Use of Predictable Algorithm in Random Number Generator)
The product requires a true random number but uses an algorithm that is predictable and generates a pseudo-random number.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Cryptographic Primitives used without Successful Self-Test - (1279)
1194 (Hardware Design) > 1205 (Security Primitives and Cryptography Issues) > 1279 (Cryptographic Primitives used without Successful Self-Test)
Using crypto primitives without ensuring that they have passed the self-tests might result in the exposure of sensitive information and/or other consequences.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Power, Clock, and Reset Concerns - (1206)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns)
Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Lock Behavior After Power State Transition - (1232)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1232 (Improper Lock Behavior After Power State Transition)
The product implements register lock bit protection features with the intent to disable changes to system configuration after the lock 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).
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Protection Against Voltage and Clock Glitches - (1247)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1247 (Missing Protection Against Voltage and Clock Glitches)
The product does not contain the necessary additional circuitry or sensors to detect and mitigate voltage and clock glitches.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Hardware 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 corruption of bits.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Missing Known Value on Reset for Registers Holding Security Settings - (1271)
1194 (Hardware Design) > 1206 (Power, Clock, and Reset Concerns) > 1271 (Missing Known Value on Reset for Registers Holding Security Settings)
The product's logic for state elements that implement security-critical functionality does not have a mechanism for being initialized to a known value on reset.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Debug and Test Problems - (1207)
1194 (Hardware Design) > 1207 (Debug and Test Problems)
Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Exposed Chip Debug and or Test Interface With Insufficient Access Control - (1191)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1191 (Exposed Chip Debug and or Test Interface With Insufficient Access Control)
The chip does not implement or does not correctly enforce access control on the debug/test interface, thus allowing an attacker to exercise the debug/test interface to access a portion of the chip internal registers that typically would not be exposed.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Hardware Internal or Debug Modes Allow Override of Locks - (1234)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1234 (Hardware Internal or Debug Modes Allow Override of Locks)
The product implements register lock bit protection features that may permit security sensitive controls to modify system configuration after the lock is set through internal modes or debug features.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Exposure of Security-Sensitive Fuse Values During Debug - (1243)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1243 (Exposure of Security-Sensitive Fuse Values During Debug)
The product exposes security-sensitive values stored in fuses during debug.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Authorization on Physical Debug and Test Interfaces - (1244)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1244 (Improper Authorization on Physical 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.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Sensitive Information Uncleared During Hardware Debug Flows - (1258)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1258 (Sensitive Information Uncleared During Hardware Debug Flows)
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Debug/Power State Transitions Leak Information - (1272)
1194 (Hardware Design) > 1207 (Debug and Test Problems) > 1272 (Debug/Power State Transitions Leak Information)
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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Cross-Cutting Problems - (1208)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems)
Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Expected Behavior Violation - (440)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 440 (Expected Behavior Violation)
A feature, API, or function being used by a product behaves differently than the product expects.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Documentation for Design - (1053)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1053 (Missing Documentation for Design)
The product does not have documentation that represents how it is designed.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insufficient Physical Protection Mechanism - (1263)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1263 (Insufficient Physical Protection Mechanism)
The product is designed such that certain parts be restricted yet does not sufficiently protect against an unauthorized actor’s ability to physically access these restricted regions of the product.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Firmware Not Updateable - (1277)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1277 (Firmware Not Updateable)
The product's firmware cannot be updated, which leaves persistent weaknesses with no means of patching them.
*BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)
1194 (Hardware Design) > 1208 (Cross-Cutting Problems) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Secrets stored in hardware can be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
+ Notes

Other

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

Other

This view attempts to present weaknesses in a simple and intuitive way. As such it targets a single level of abstraction. It is important to realize that not every CWE will be represented in this view. High-level class weaknesses and low-level variant weaknesses are mostly ignored. However, by exploring the weaknesses that are included, and following the defined relationships, one can find these higher and lower level weaknesses.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses59out of 875
Categories12out of 312
Views0out of 39
Total71out of1226
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE

View Components

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

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.696Incorrect Behavior Order
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction

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

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

Languages

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 Consequences

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

ScopeImpactLikelihood
Access Control
Confidentiality
Integrity

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

+ Demonstrative Examples

Example 1

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

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

output reg [7:0] data_out;;

input wire [2:0] usr_id;

input wire [7:0] data_in;

input wire clk, rst_n;

wire grant_access;

always @ (posedge clk or negedge rst_n)

begin

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

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

(good code)
Example Language: Verilog 

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

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

Phase: Implementation

Implement the access control check first. Access should only be given to asset if agent is authorized.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1268: Agents Included in Control Policy are not Contained in Less-Privileged Policy

Weakness ID: 1268
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.
+ Extended Description

Integrated circuits and hardware engines may provide access to resources (device-configuration, encryption keys, etc.) belonging to trusted firmware or software modules (commonly set by a BIOS or a bootloader). These accesses are typically controlled and limited by the hardware. Hardware design access control is sometimes implemented using a policy. A policy defines which entity or agent may or may not be allowed to perform an action. When a system implements multiple levels of policies, a control policy may allow direct access to a resource as well as changes to the policies themselves.

Such resources that include agents in the control policy but not in write policy could unintentionally allow the untrusted agent to insert itself in the write policy register. Inclusion in the write policy register could allow a malicious or misbehaving agent write access to resources. This action could result in security risks consisting of leaked information, leaked encryption keys, or even modification of device configuration.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignThis weakness may be introduced during the design of a device when the architect does not sufficiently specify which policies may run an agent to effect policy changes.
ImplementationThis weakness may be introduced during the implementation of a device misses restrictions required of agents being run by less-priviledged clients.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Modify Memory; Read Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Read Files or Directories; Reduce Reliability

High
+ Demonstrative Examples

Example 1

Consider a system with a register for storing an AES key for encryption or decryption. The key is composed of 128 bits implemented as a set of four 32-bit registers. The key registers are resources and registers, AES_KEY_CONTROL_POLICY, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary, access controls.

The control-policy register defines which agents can write to the read-policy and write-policy registers. The read-policy register defines which agents can read the AES-key registers, and write-policy register defines which agents can program or write to those registers. Each 32-bit register can support access control for a maximum of 32 agents. 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.

(bad code)
 
RegisterField description
AES_ENC_DEC_KEY_0AES key [0:31] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_1AES key [32:63] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_2AES key [64:95] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_3AES key [96:127] for encryption or decryption
Default 0x00000000
AES_KEY_CONTROL_POLICY[31:0] Default 0x00000018, meaning agent with identities “4” and “3” has read/write access to this register (i.e., AES_KEY_CONTROL_POLICY), AES_KEY_READ_POLICY, and AES_KEY_WRITE_POLICY registers
AES_KEY_READ_POLICY[31:0] Default 0x00000002, agent with identity “1” can only read AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers
AES_KEY_WRITE_POLICY[31:0] Default 0x00000004, agent with identity “2” can only write to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers

In the above example, the AES_KEY_CONTROL_POLICY register has agents with identities “4”and “3” in its policy. Assuming the agent with identity “4” is trusted and the agent with identity “3” is untrusted. The untrusted agent “3” can write to AES_KEY_WRITE_POLICY with a value of 0x0000000C thus allowing write access to AES_ENC_DEC_KEY_0 through AES_ENC_DEC_KEY_3 registers.

  1. The AES_KEY_CONTROL_POLICY defines which agents have write access to the AES_KEY_CONTROL_POLICY, AES_KEY_READ_POLICY, and the AES_KEY_WRITE_POLICY registers,
  2. The AES-key registers can only be read or used by a crypto agent with identity “1” when bit #1 is set.
  3. The AES-key registers can only be programmed by a trusted firmware with identity “2” when bit #2 is set.

For the above example, the control, read-and-write-policy registers’ values are defined as below.

(good code)
 
RegisterField description
AES_KEY_CONTROL_POLICY[31:0] Default 0x00000010, meaning only agents with an identity of “4” have read/write access to this register (i.e., AES_KEY_CONTROL_POLICY), AES_KEY_READ_POLICY, and AES_KEY_WRITE_POLICY registers
AES_KEY_READ_POLICY[31:0] Default 0x00000002, meaning only trusted firmware with an identity of “1” can program registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3
AES_KEY_WRITE_POLICY[31:0] Default 0x00000004, meaning only trusted firmware with an identity of “2” can program registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3
+ Potential Mitigations

Phase: Architecture and Design

Access-control-policy definition and programming flow must be tested in pre-silicon and post-silicon testing

Phase: Implementation

Access-control-policy definition and programming flow must be tested in pre-silicon and post-silicon testing
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.668Exposure of Resource to Wrong Sphere
CanPrecedeBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.471Modification of Assumed-Immutable Data (MAID)
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Modes Of Introduction

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

PhaseNote
ImplementationKeys, code, configuration settings, and other data can be programmed in writable memory instead of write-once or read-only memory.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

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

+ Potential Mitigations

Phase: Implementation

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

Maintenance

This entry is still in under development and will continue to see updates and content improvements, especially as it relates to CWE-1233.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-15Nicole FernTortuga Logic

CWE CATEGORY: Core and Compute Issues

Category ID: 1201
Status: Draft
+ Summary
Weaknesses in this category are typically associated with CPUs, Graphics, Vision, AI, FPGA, and microcontrollers.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1252CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1281Sequence of Processor Instructions Leads to Unexpected Behavior (Halt and Catch Fire)
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1201Core and Compute Issues
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Microcontroller IP (Undetermined Prevalence)

Processor IP (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

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

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

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

+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Integration

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

+ References
[REF-1077] Intel. "MCS 51 Microcontroller Family User's Manual". <http://web.mit.edu/6.115/www/document/8051.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-13Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE CATEGORY: Cross-Cutting Problems

Category ID: 1208
Status: Draft
+ Summary
Weaknesses in this category can arise in multiple areas of hardware design or can apply to a wide cross-section of components.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.440Expected Behavior Violation
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1053Missing Documentation for Design
HasMemberClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1263Insufficient Physical Protection Mechanism
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1277Firmware Not Updateable
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1278Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE-1279: Cryptographic Primitives used without Successful Self-Test

Weakness ID: 1279
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Using crypto primitives without ensuring that they have passed the self-tests might result in the exposure of sensitive information and/or other consequences.
+ Extended Description

Cryptographic primitives are hardware units that are supposed to perform certain cryptographic tasks. As is the case with many systems, for both hardware and software, in order to perform correctly, a system must first attain a certain state that can be considered a valid, starting point. In other words, it can be stated that the system has now been properly initialized. However, in order to reach this valid, initial state, the system needs to have performed certain tasks and/or obtained certain other data from other parts of the system. For example, a cryptographic unit that depends on an external, random-number-generator (RNG) unit for entropy must get a signal from the RNG unit that the RNG unit is ready to supply random numbers if asked. Or maybe a symmetric, cryptographic unit retrieves its private encryption key from a fuse unit; hence, it must ensure that the fuse unit is up and running before it can pull the fuse with the corresponding key.

However, even when the system reaches this supposedly valid, initial state, the system must “validate” that this state is indeed valid. To do this, the system performs a series of tests and compares the result with the expected values. This test is often called Power-On Self-Test (POST), Built-In Self-test (BIST), or just self-test in short. If the results of the self-test do not match the expected values, then the system assumes that something went wrong with the initialization process, and, resultingly, the system can no longer be trusted to perform its tasks reliably.

To ensure the sanctity of the self-test process, when the self-test goes on, usually the regular input, output, and other external interfaces are not made available.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.665Improper Initialization
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and Design
ImplementationThe decision to continue using a crypto primitive despite unsuccessful self-test may be taken at any phase. As is the case with any process, any extra logic costs silicon real estate and resources. For example, in order to properly perform self-tests, one must store the “expected answers” somewhere. If there are many such answers that need to be stored, that consumes precious, non-volatile-storage space. An architect who wants to keep the silicon footprint to a minimum at any cost might choose to forego the self-test infrastructure. Or, it might be possible that silicon real estate is not a problem, but latency is – the crypto system must be up and running as soon as possible, and self-test takes time to execute. Therefore, a decision might be taken later that self-tests may be omitted to hasten up the boot process. Another possible scenario could be where the self-test is allowed to run, but, even if the result is not 100% correct, the system is still allowed to be used for business reasons (where the crypto system is not in the critical path).
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

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 Consequences

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

ScopeImpactLikelihood
Access Control
Confidentiality
Integrity
Availability
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

Usage of crypto primitives without successful self-test could render the supposedly encrypted data as unencrypted plaintext in the worst case. This would compromise any security property, including the ones listed above.
+ Demonstrative Examples

Example 1

The following pseudocode demonstrates this vulnerability where the architect deemed it OK to ignore the result of a self-test from an RNG. Assume the output from the RNG is used to seed yet another pseudo-random-number generator.

(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 we are checking if the RNG is ready by performing a self-test on the RNG. If it fails, we just ignore the result and use some hardcoded, constant value. This action of ignoring the self-test result and using a constant seed is going to reduce the entropy of the cryptographic function using that seed and thereby weaken it.

(good code)
Example Language: Other 

If random_number_generator_self_test_passed() == TRUE

then Seed = get_random_number_from_RNG()

else enter_error_state()

+ Potential Mitigations

Phase: Architecture and Design

Follow sensible 'best practices' for crypto system design. For example, ensure the crypto system performs a power-on self-test at boot time, and that self-test results can't be ignored or overridden.

Effectiveness: High

Phase: Implementation

Depending on the specific cryptographic function the unit is providing, it might be necessary to perform additional, conditional self-tests periodically, e.g., using pairwise-consistency tests for RSA, DSA, and ECDSA signature keys. Also, the system should be insulated from all influences during self-test--no input signals allowed.

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE CATEGORY: Debug and Test Problems

Category ID: 1207
Status: Draft
+ Summary
Weaknesses in this category are related to hardware debug and test interfaces such as JTAG and scan chain.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1191Exposed Chip Debug and or Test Interface With Insufficient Access Control
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1234Hardware Internal or Debug Modes Allow Override of Locks
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1243Exposure of Security-Sensitive Fuse Values During Debug
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1244Improper Authorization on Physical Debug and Test Interfaces
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1258Sensitive Information Uncleared During Hardware Debug Flows
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1272Debug/Power State Transitions Leak Information
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE-1272: Debug/Power State Transitions Leak Information

Weakness ID: 1272
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Extended Description

A device or system frequently employs many power and sleep states during its normal operation (e.g., normal power, additional power, low power, hibernate, deep sleep, etc.). Similarly, depending on the supplied credentials, a device may be operating within a debug condition. For example, a hypothetical enumeration of debug levels may be:

  • Level 1 (fully open, all debug methods available)
  • Level 2 (partially open, some debug methods available), and
  • Level 3 (not open, minimal to no debug methods available).

Depending on various factors, state transitions can happen from one power or debug state to another. If there is information available in the current state and it is not properly removed before the next transistion state, there can be sensitive information leakage.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.664Improper Control of a Resource Through its Lifetime
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction

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

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

Languages

VHDL (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

Class: Compiled (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Other (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Read Memory; Read Application Data

Depending on the information that is compromised, an attacker can use that information to unlock additional capabilities of the device and take advantage of hidden functionalities. This could compromise any security property, including the ones listed above.
High
+ Demonstrative Examples

Example 1

This example shows how an attacker can take advantage of an incorrect, power/debug-state transition.

(bad code)
 

Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in B. It reads those keys, performs certain operations, and then transitions to state B where those private keys are no longer accessible.

However, during this transition, it does not scrub the memory. So, at this moment, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory, which contains the footprint of the private keys.

It is essential to consider not just the source of the secrets but, rather, perform a taint analysis of how far the secrets have traveled.

(good code)
 
For transition from state A to state B, do a taint analysis of where confidential information has propagated. Make sure all secrets from all such locations are removed during the transition.
+ Potential Mitigations

Phase: Architecture and Design

During state transitions, it is essential that the device also take appropriate action to scrub the secrets that are available in the current state but should not be available in the next state.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-31Parbati Kumar Manna, Hareesh Khattri, Arun KanuparthiIntel Corporation

CWE-1273: Device Unlock Credential Sharing

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

“Unlocking a device” often means activating certain, unadvertised, debug and manufacturer-specific capabilities of a device using sensitive credentials. Unlocking a device might be necessary for the purpose of troubleshooting device problems. For example, suppose a device contains the ability to dump the content of the full system memory by disabling the memory-protection mechanisms. Since this is a highly security-sensitive capability, this capability is “locked” in the production part. Unless the device gets unlocked by supplying the proper credentials the debug 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.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.200Exposure of Sensitive Information to an Unauthorized Actor
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1195Manufacturing and Life Cycle Management Concerns
+ Modes Of Introduction

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

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

Languages

VHDL (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

Class: Compiled (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Other (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

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

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

Example 1

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

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

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

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

Phase: Integration

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

Phase: Manufacturing

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

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-29Parbati Kumar Manna, Hareesh Khattri, Arun KanuparthiIntel Corporation

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.696Incorrect Behavior Order
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism; Modify Memory

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

Phase: Architecture and Design

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

CWE-440: Expected Behavior Violation

Weakness ID: 440
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
A feature, API, or function being used by a product behaves differently than the product expects.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.684Incorrect Provision of Specified Functionality
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

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

Theoretical

The consistency dimension of validity is the most appropriate relevant property of an expected behavior violation. That is, the behavior of the application is not consistent with the expectations of the developer, leading to a violation of the validity property of the software.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExpected behavior violation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relevant_Properties, Theoretical_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships

CWE-1191: Exposed Chip Debug and or Test Interface With Insufficient Access Control

Weakness ID: 1191
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The chip does not implement or does not correctly enforce access control on the debug/test interface, thus allowing an attacker to exercise the debug/test interface to access a portion of the chip internal registers that typically would not be exposed.
+ Extended Description

Integrated circuits can expose the chip internals through a scan chain interconnected through internal registers etc., through scan flip-flops. A Joint Test Action Group (JTAG) compatible test access port usually provides access to this scan chain for debugging the chip. Since almost every asset in the chip can be accessed over this debug interface, chip manufacturers typically insert some form of password-based or challenge-response based access control mechanisms to prevent misuse. This mechanism is implemented in addition to on-chip protections that are already present. If this debug access control is not implemented or the access control check is not implemented properly, or if the hardware does not clear secret keys, etc., when debug more is entered, an attacker may be able to bypass on-chip access control mechanisms through debug features/interfaces.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
PeerOfClassClass - 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.1263Insufficient Physical Protection Mechanism
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

High
Confidentiality

Technical Impact: Read Memory

High
Authorization

Technical Impact: Execute Unauthorized Code or Commands

High
Integrity

Technical Impact: Modify Memory

High
Integrity

Technical Impact: Modify Application Data

High
Access Control

Technical Impact: Bypass Protection Mechanism

High
+ Demonstrative Examples

Example 1

A home, WiFi-router device implements a standard, login prompt, which prevents an attacker from issuing any commands on the device until appropriate credentials are provided. The credentials are secret, and they are not from the well-known list of poor credentials.

(bad code)
Example Language: Other 

If JTAG interface on this device is not hidden by the manufacturer, it can be identified using tools such as JTAGulator. If it is hidden but not disabled, it can be exposed by using a soldering engine.

By issuing a halt command before the OS starts, the attacker pauses the watchdog timer and prevents the router from restarting (once the watchdog timer expires). Having paused the router, attacker sets breakpoints and is capable of stepping through operations and inspecting/injecting data in the device’s memory. Through analysis of the extracted firmware from the device, attacker identifies the exact pattern to inject to the device memory. After injecting this pattern, attacker successfully launches a shell on the device.

JTAG is useful to chip manufacturers during design, testing, and production and is included in nearly every product. However, it also serves as a huge, potential, attack vector if it is exposed to an attacker. Appropriate measures need to be taken to prevent misuse of this powerful interface.

(good code)
Example Language: Other 
In order to prevent exposing debug interface, manufacturers might try to obfuscate JTAG interface or deliberately blow fuses in the JTAG interface. Sometimes, they are hidden in inner layers of the board. If interface has to be exposed, adding access-control protection to this interface would also prevent misuse.
+ Observed Examples
ReferenceDescription
chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Implement an access control mechanism to exercise the debug interface in order to control and observe security-sensitive chip internals.

Password checking logic should be resistant to timing attacks. Security-sensitive data stored in registers, such as keys, etc. should be cleared when entering debug mode.

+ References
[REF-1037] Kurt Rosenfeld and Ramesh Karri. "Attacks and Defenses for JTAG". 2010-02. <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5406671>.
[REF-1043] Gopal Vishwakarma and Wonjun Lee. "Exploiting JTAG and Its Mitigation in IOT: A Survey". 2018-12-03. <https://www.mdpi.com/1999-5903/10/12/121/pdf>.
[REF-1084] Gopal Vishwakarma and Wonjun Lee. "JTAG Explained (finally!): Why “IoT”, Software Security Engineers, and Manufacturers Should Care". <https://www.mdpi.com/1999-5903/10/12/121/pdf >.
[REF-1085] Bob Molyneaux, Mark McDermott and Anil Sabbavarapu. "Design for Testability & Design for Debug". <http://users.ece.utexas.edu/~mcdermot/vlsi-2/Lecture_17.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, References, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-26Exposed Chip Debug Interface With Insufficient Access Control

CWE-1243: Exposure of Security-Sensitive Fuse Values During Debug

Weakness ID: 1243
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product exposes security-sensitive values stored in fuses during debug.
+ Extended Description

Several security-sensitive values are blown as fuses in a chip to be used during early-boot flows or later at runtime. Examples of these security-sensitive values include root keys, encryption keys, manufacturing-specific information, chip-manufacturer-specific information, and original-equipment-manufacturer (OEM) data. After the chip is powered on, these values are sensed from fuses and stored in temporary locations such as registers and local memories. These locations are typically access-control protected from untrusted agents capable of accessing them. Even to trusted agents, only read-access is provided. However, these locations are not blocked during debug flows, allowing an untrusted debugger to access these assets and compromise system security.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.200Exposure of Sensitive Information to an Unauthorized Actor
PeerOfClassClass - 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.1263Insufficient Physical Protection Mechanism
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Modify Memory; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Secret manufacturing data (such as die information) are stored in fuses. While the chip powers on, this value is sensed from fuses and is stored in a microarchitectural register. This register is only given read access to trusted software running on the core. Untrusted software running on the core cannot access it.

(bad code)
Example Language: Other 
All microarchitectural registers in this chip can be accessed through the debug interface. As a result, even an untrusted debugger can access this data and get hold of secret manufacturing data.
(informative)
 
Registers used to store security-sensitive values sensed from fuses should be blocked on debug. They should be disconnected from the debug interface.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

When in debug mode, disable access to security-sensitive values sensed from fuses and stored in temporary locations.

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE-1209: Failure to Disable Reserved Bits

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.710Improper Adherence to Coding Standards
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignThe Designer and Implementer have to make a conscious choice to do this
ImplementationThe Designer and Implementer have to make a conscious choice to do this
DocumentationIf documentation labels anything "for future use", "reserved", or the like, such labeling could indicate to an attacker a potential attack point
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

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

Example 1

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

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

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

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

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

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

Phases: Architecture and Design; Implementation

Include a feature disable

Phase: Integration

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

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-06Brent ShermanIntel Corporation

CWE-1277: Firmware Not Updateable

Weakness ID: 1277
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product's firmware cannot be updated, which leaves persistent weaknesses with no means of patching them.
+ Extended Description

The 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 present. External protective measures and mitigations can be employed to aid in preventing malicious behavior, but the root weakness cannot be corrected.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.664Improper Control of a Resource Through its Lifetime
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction

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

PhaseNote
RequirementsThe weakness can appear through oversight during requirements development.
Architecture and DesignThe weakness can appear due to lack of planning during architecture development and design.
ImplementationThe weakness can appear through oversight during implementation.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Access Control
Authentication
Authorization

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

An attacker can leverage access to (or mapping of) the firmware to gain unauthorized access to the system's operation and configuration information. This knowledge can be used to determine the most effective method of exploiting the present weakness(es). If an attacker can identify a flaw in a device that can be exploited, this attack may apply across the entire class of devices since they cannot be updated. Likelihood of negative impact will depend on the prevalence and accessibility of the devices. If they are commodity (home) use devices, they are highly likely to be experimented on. If limited use commercial devices (low accessibility) then the likelihood is lower.
Medium
+ Demonstrative Examples

Example 1

An employee’s mobile device is decommissioned due to end of life but sensitive user information, network certificates, and encryption keys are left in device memory/storage.

(bad code)
Example Language: Other 
This device is obtained by a malicious individual; either through re-seller or nefarious means. System forensics (e.g. chip decapping) is used to reveal system memory and storage data. Examination of these leads to acquisition of critical and/or sensitive data which can be used to bypass access control, impersonate individuals, or otherwise access potentially proprietary information.
(good code)
Example Language: Other 
Device is scrubbed of sensitive/critical information prior to decommissioning (e.g. resell or disposal). Once obtained by another individual, they are unable to extract any critical or sensitive data since it is not present on the device.
+ Potential Mitigations

Phase: Requirements

Specify requirements to provide the ability to update firmware.

Phase: Architecture and Design

Design the device to allow for updating the firmware.

Phase: Implementation

Implement necessary functionality to allow for updating the firmware.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ References
[REF-1095] Matthew Hughes. "Bad news: KeyWe Smart Lock is easily bypassed and can't be fixed". <https://www.theregister.com/2019/12/11/f_secure_keywe/>.
[REF-1096] Alex Scroxton. "Alarm bells ring, the IoT is listening". <https://www.computerweekly.com/news/252475324/Alarm-bells-ring-the-IoT-is-listening>.
[REF-1097] Brian Krebs. "Zyxel Flaw Powers New Mirai IoT Botnet Strain". <https://krebsonsecurity.com/2020/03/zxyel-flaw-powers-new-mirai-iot-botnet-strain/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-13Paul A. WortmanWells Fargo

CWE CATEGORY: General Circuit and Logic Design Concerns

Category ID: 1199
Status: Draft
+ Summary
Weaknesses in this category are related to hardware-circuit design and logic (e.g., CMOS transistors, finite state machines, and registers) as well as issues related to hardware description languages such as System Verilog and VHDL.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1209Failure to Disable Reserved Bits
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1221Incorrect Register Defaults or Module Parameters
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1223Race Condition for Write-Once Attributes
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1224Improper Restriction of Write-Once Bit Fields
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1231Improper Implementation of Lock Protection Registers
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1232Improper Lock Behavior After Power State Transition
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1233Improper Hardware Lock Protection for Security Sensitive Controls
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1234Hardware Internal or Debug Modes Allow Override of Locks
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1245Improper Finite State Machines (FSMs) in Hardware Logic
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1253Incorrect Selection of Fuse Values
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1254Incorrect Comparison Logic Granularity
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1259Improper Protection of Security Identifiers
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1261Improper Handling of Single Event Upsets
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1270Generation of Incorrect Security Identifiers
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE-1270: Generation of Incorrect Security Identifiers

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

Systems-On-Chip (Integrated circuits and hardware engines) implement Security Identifiers to differentiate/identify actions originated from various agents. These actions could be ‘read’, ‘write’, ‘program’, ‘reset’, ‘fetch’, ‘compute’, etc. Security identifiers are generated and assigned to every agent in the System (SoC) that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Identifier based on its trust level or privileges. Hence the generation of the Security Identifiers is very important to achieve security in the SoC. A common weakness that can exist is that the generated Security Identifiers are incorrect. Consequently, the same agent may have multiple identifiers or multiple agents may have the same security identifier. In either case, the security consequences could be a Denial-of-Service (DoS) or execution of an action that in turn could result in privilege escalation or unintended access.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1259Improper Protection of Security Identifiers
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design phases.
ImplementationSuch issues could be introduced during implementation and identified later during testing or system configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Processor IP Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

High
+ Demonstrative Examples

Example 1

For example, consider a system with a register for storing AES key for encryption or decryption. The key is of 128 bits 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 with a security identifier in the transaction can access the AES-key registers. Each bit in this 32-bit register defines a security identifier. There could be a maximum of 32 security identifiers 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 Identifiers are “1” and “2”.

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

An agent with Security Identifier “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 identifier is “1”.

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

Both agents have access to the AES-key registers.

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

Phases: Architecture and Design; Implementation

  • Generation of Security Identifiers must be reviewed for design inconsistency and common weaknesses.
  • Security-Identifier definition and programming flow must be tested in pre-silicon and post-silicon testing.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-03-06Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1276: Hardware Block Incorrectly Connected to Larger System

Weakness ID: 1276
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Signals between a hardware IP and the larger system design are incorrectly connected.
+ Extended Description

Individual hardware IP must communicate with the larger system in order for the product to function correctly and as intended. If implemented incorrectly, these various inputs and output interactions may cause security issues that will not necessarily manifest as functional bugs. For example, if the IP should only be reset by a system-wide hard reset, but instead the reset input is connected to a software-triggered debug mode reset (which is also asserted during a hard reset), integrity of data inside the IP can be violated.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1197Integration Issues
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Many SoCs use hardware to partition system resources between secure/trusted and non-secure/un-trusted entities. An example of this is Arm TrustZone, in which the processor and all security-aware IP must 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 can 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 larger 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 larger system

module soc(...)

...

tz_peripheral u_tz_peripheral(

.clk(clk),

.rst(rst),

.data_in(rdata),

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

.data_in_security_level(rdata_security_level),

);

...

endmodule

+ Potential Mitigations

Phase: Testing

System-level verification is essential to ensure that components are correctly connected and that design security requirements are not violated due to interactions between various IP blocks.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-22Nicole FernTortuga Logic

CWE-1256: Hardware Features Enable Physical Attacks from Software

Weakness ID: 1256
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Software-controllable device functionality such as power and clock management permits unauthorized corruption of bits.
+ Extended Description

Fault injection attacks involve strategic corruption of bits in a hardware design 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. It is commonly assumed that an attacker requires physical access to the device to succeed in injecting faults. This assumption is false if the device has improperly secured power management features that allow untrusted programs to manipulate 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).

+ Relationships

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

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

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

Memory IP (Undetermined Prevalence)

Power Management IP (Undetermined Prevalence)

Clock/Counter IP (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity

Technical Impact: Modify Memory; Modify Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Suppose a hardware design implements a set of software-accessible registers for scaling clock frequency and voltage but does not block writes to these registers based on privilege level.

+ Observed Examples
ReferenceDescription
Plundervolt: Improper conditions check in voltage settings for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege and/or information disclosure via local access.
NaCl in 2015 allowed the CLFLUSH instruction, making rowhammer attacks possible.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.

+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ References
[REF-1081] Kit Murdock, David Oswald, Flavio D Garcia, Jo Van Bulck, Frank Piessens and Daniel Gruss. "Plundervolt". <https://plundervolt.com/>.
[REF-1082] Adrian Tang, Simha Sethumadhavan and Salvatore Stolfo. "CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management". <https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-tang.pdf>.
[REF-1083] Yoongu Kim, Ross Daly, Jeremie Kim, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai and Onur Mutlu. "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors". <https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-08Nicole FernTortuga Logic

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

Weakness ID: 1234
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product implements register lock bit protection features that may permit security sensitive controls to modify system configuration after the lock is set through internal modes or debug features.
+ Extended Description

In 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. 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, they may allow modification of the lock protection.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.667Improper Locking
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

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

Example 1

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

(bad code)
Example Language: Verilog 

module Locked_register_example
(
input [15:0] Data_in,
input Clk,
input resetn,
input write,
input Lock,
input scan_mode,
input debug_unlocked,
output reg [15:0] Data_out
);

reg lock_status;

always @(posedge Clk or negedge resetn)
if (~resetn) // Register is reset resetn
begin
lock_status <= 1'b0;
end
else if (Lock)
begin
lock_status <= 1'b1;
end
else if (~Lock)
begin
lock_status <= lock_status
end

always @(posedge Clk or negedge resetn)
if (~resetn) // Register is reset resetn
begin
Data_out <= 16'h0000;
end
else if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported for scan_mode & debug_unlocked
begin
Data_out <= Data_in;
end
else if (~write)
begin
Data_out <= Data_out;
end

endmodule

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

(good code)
 
Remove debug and scan mode overrides. Or protect enabling of these modes through secure authentication and authorization features, such that only trusted and authorized users can enable these debug modes.
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security Lock bit protections must be reviewed for any bypass/override modes supported.
  • Any supported override modes either must be removed, or these modes should be protected using features like secure authenticated, authorized debug modes.
  • Security lock programming flow and lock properties must be tested in pre-si, post-si testing.

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiiIntel Corporation

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.821Incorrect Synchronization
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1037Processor Optimization Removal or Modification of Security-critical Code
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignThe weakness can be introduced in the data transfer or bus protocol itself or in the implementation.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory; Read Application Data

+ Demonstrative Examples

Example 1

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

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

Phase: Architecture and Design

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

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-22Nicole FernTortuga Logic

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

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

Hardware product designs often need to implement memory protection features that enable privileged software to define isolation 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 must 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 decode logic. If one of the memory regions is corrupted or faults, then the hardware can switch to using the data in the mirrored memory region. Memory aliases can also be created in 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 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 and read or modify the protected memory.

An untrusted agent can also maliciously create memory aliases in the system address map if it is able to change the mapping of an address region or modify memory region sizes.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design or implementation and identified later during Testing phase.
ImplementationSuch issues could be introduced during hardware architecture and design or implementation and identified later during Testing phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

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 Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

High
Integrity

Technical Impact: Modify Memory

High
Availability

Technical Impact: DoS: Instability

High
+ Demonstrative Examples

Example 1

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

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

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

The address decoder of Unit_A masks off the higher order address bits and decodes only lower 12bits 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

Such that the same register can be accessed using four different addresses (e.g. 0x0000, 0x1000,0x2000,0x3000 all map to same register in Unit_A).

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

(good code)
Example Language: Other 

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

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

+ Potential Mitigations

Phases: Architecture and Design; Implementation

The same memory access control checks must be applied for any mirrored or aliased memory regions. If different memory protection units (MPU) are protecting the aliased regions, their protected range definitions and policies must be synchronized.

Phases: Architecture and Design; Implementation

The controls that allow enabling memory aliases or changing size of mapped memory regions must only be programmable by trusted software components.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-04-29Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1244: Improper Authorization on Physical Debug and Test Interfaces

Weakness ID: 1244
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Extended Description

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.285Improper Authorization
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

Integrity

Technical Impact: Modify Memory

Authorization
Access Control

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

+ Demonstrative Examples

Example 1

JTAG interface is used to perform debugging and providing insights into the CPU core for developers. JTAG-access protection is implemented as part of the JTAG_SHIELD bit in the register hw_digctl_ctrl REGISTER. This register is not set by default and is set after the system boots from ROM, and control is transferred to the user software.

(bad code)
Example Language: Other 
1 bit 0x0 = JTAG debugger is enabled (default)
JTAG_SHIELD 0x1 = JTAG debugger is disabled

This means that end user has access to JTAG at system reset and during ROM code execution before control is transferred to user software. With this loophole, an attacker can modify the boot flow and subsequently disclose data-encryption keys.

(informative)
 
The default value of this register bit should be set to 1. This prevents JTAG being enabled at system reset.
+ Observed Examples
ReferenceDescription
JTAG access is disabled after ROM code execution. This means that JTAG access is possible when the system is running code from ROM before transferring control over to embedded firmware. This allows an attacker to modify boot flow and successfully bypass secure-boot process.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

For security-sensitive assets accessible over debug/test interfaces, only allow trusted agents.

+ References
[REF-1056] F-Secure Labs. "Multiple Vulnerabilities in Barco Clickshare: JTAG access is not permanently disabled". <https://labs.f-secure.com/advisories/multiple-vulnerabilities-in-barco-clickshare/>.
[REF-1057] Kurt Rosenfeld and Ramesh Karri. "Attacks and Defenses for JTAG". <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5406671>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.684Incorrect Provision of Specified Functionality
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Availability
Access Control

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

+ Demonstrative Examples

Example 1

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

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

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

endcase

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

endmodule

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

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

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

endcase
+ Potential Mitigations

Phases: Architecture and Design; Implementation

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

Effectiveness: High

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

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

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

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

If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege software a weakness is available for abuse. 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.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design or implementation and identified later during Testing phase.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Memory IP (Undetermined Prevalence)

Processor IP (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

High
+ Demonstrative Examples

Example 1

For example, consider an example design with 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.

- Region_0 & Region_1: registers are programmable by Privilege_SW

- Region_2: registers are programmable by Non_privilege_SW

Each region range is defined by two 32 bit registers Address_range and Access_policy:

- Address_range[15:0]: specifies the Base address of the region

- Address_range[31:16]: specifies the size of the region

- Access_policy[0]: if set to one, allows reads from Non_privilege_SW

- Access_policy[1]: if set to one, allows writes from Non_privilege_SW

- Access_policy[0]: if set to one, allows reads from Privilege_SW

- Access_policy[1]: if set to one, allows writes from Privilege_SW

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
ReferenceDescription
Intel Desktop and Intel Mobile Boards with BIOS firmware DQ35JO, DQ35MP, DP35DP, DG33FB, DG33BU, DG33TL, MGM965TW, D945GCPE, and DX38BT allow local administrators with ring 0 privileges to gain additional privileges and modify code that is running in System Management Mode, or access hypervisor memory as demonstrated at Black Hat 2008 by accessing certain remapping registers in Xen 3.3.
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Implementation

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

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

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

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

Effectiveness: High

+ References
[REF-1100] Christopher Domas. "The Memory Sinkhole". 2015-07-20. <https://github.com/xoreaxeaxeax/sinkhole/blob/master/us-15-Domas-TheMemorySinkhole-wp.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1261: Improper Handling of Single Event Upsets

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.755Improper Handling of Exceptional Conditions
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1254Incorrect Comparison Logic Granularity
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Availability
Access Control

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

+ Demonstrative Examples

Example 1

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

Parity is error detecting but not error correcting.

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

Example 2

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

+ Potential Mitigations

Phase: Architecture and Design

Implement triple-modular redundancy around security-sensitive modules.

Phase: Architecture and Design

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

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

CWE-1233: Improper Hardware Lock Protection for Security Sensitive Controls

Weakness ID: 1233
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product implements a register lock bit protection feature that permits security sensitive controls to modify the protected configuration.
+ Extended Description

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.667Improper Locking
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Modify Memory

System Configuration protected by the lock bit can be modified even when the lock is set.
+ Demonstrative Examples

Example 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 
Register Field description
CRITICAL_TEMP_LIMIT [31:8]
Reserved field;
Read only;
Default 0
[7:0]
Critical temp 0-255 Centigrade;
Read-write-lock; Default 125
TEMP_SENSOR_CALIB [31:0]
Thermal sensor calibration data. A slope value used to map sensor reading to a degree Centigrade.
Read-write;
Default 25
TEMP_SENSOR_LOCK [31:1]
Reserved field;
Read only;
Default 0 [0] Lock bit, locks CRITICAL_TEMP_LIMIT register;
Write-1-once;
Default 0
TEMP_HW_SHUTDOWN [31:2]
Reserved field;
Read only;
Default 0 [1] Enable hardware shutdown on a critical temperature detection;
Read-write;
Default 0
CURRENT_TEMP [31:8]
Reserved field;
Read only;
Default 0
[7:0]
Current Temp 0-255 Centigrade;
Read-only;
Default 0

In this example note that 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.

TEMP_SENSOR_CALIB [31:8]
Thermal sensor calibration data. A slope value used to map sensor reading to a degree Centigrade.
Read-write-Lock;
Default 25
Locked by TEMP_SENSOR_LOCK bit[0]
TEMP_HW_SHUTDOWN [31:2]
Reserved field;
Read only;
Default 0
[1] Enable hardware shutdown on critical temperature detection;
Read-write-Lock;
Default 0
Locked by TEMP_SENSOR_LOCK bit[0]
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Security lock bit protections must be reviewed for design inconsistency and common weaknesses.
  • Security lock bit protections must be reviewed common weaknesses.
  • Security lock programming flow and lock properties must be tested in pre-si, post-si testing.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1231: Improper Implementation of Lock Protection Registers

Weakness ID: 1231
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product incorrectly implements register lock bit protection features such that protected controls can be programmed even after the lock has been set.
+ Extended Description

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

+ Relationships

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

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

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Modify Memory

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

Example 1

Consider the example design below 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 
Register Field description
CRITICAL_TEMP_LIMIT [31:8] Reserved field; Read only; Default 0
[7:0] Critical temp 0-255 Centigrade; Read-write-lock; Default 125
TEMP_SENSOR_CALIB [31:0] Thermal sensor calibration data. Slope value used to map sensor reading to degree Centigrade.
TEMP_SENSOR_LOCK [31:1] Reserved field; Read only; Default 0
[0] Lock bit, locks CRITICAL_TEMP_LIMIT and TEMP_SENSOR_CALIB registers; Write-1-once; Default 0
TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0
[1] Enable hardware shutdown on critical temperature detection; Read-write; Default 0
CURRENT_TEMP [31:8] Reserved field; Read only; Default 0
[7:0] Current Temp 0-255 Centigrade; Read-only; Default 0

In this example note that 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.

TEMP_HW_SHUTDOWN [31:2] Reserved field; Read only; Default 0
[1] Enable hardware shutdown on critical temperature detection; Read-write-Lock; Default 0
[0] Locked by TEMP_SENSOR_LOCK
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

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

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples

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

Weakness ID: 1189
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product does not properly isolate shared resources between trusted and untrusted agents.
+ Extended Description

A System-On-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.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.668Exposure of Resource to Wrong Sphere
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

If shared resources are being used by a trusted user, it may be possible for untrusted agents to modify the functionality of the shared resource for the trusted user.
Integrity

Technical Impact: Quality Degradation

The functionality of the shared resource may be intentionally degraded.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

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

Group untrusted agents together to access when sharing a resource. Similarly, group trusted agents (at same trust level).

+ Detection Methods

Automated Static Analysis - Binary or Bytecode

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

Effectiveness: High

+ References
[REF-1036] Ali Abbasi and Majid Hashemi. "Ghost in the PLC Designing an Undetectable Programmable Logic Controller Rootkit via Pin Control Attack". 2016. <https://www.blackhat.com/docs/eu-16/materials/eu-16-Abbasi-Ghost-In-The-PLC-Designing-An-Undetectable-Programmable-Logic-Controller-Rootkit-wp.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1232: Improper Lock Behavior After Power State Transition

Weakness ID: 1232
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product implements register lock bit protection features with the intent to disable changes to system configuration after the lock 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).
+ Extended Description

Integrated 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. In hardware design this is commonly implemented using a programmable lock bit, which when set disables writes to a protected set of registers or address regions.

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.667Improper Locking
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1206Power, Clock, and Reset Concerns
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design or implementation and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during hardware architecture and design or implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Modify Memory

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

Example 1

Consider 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 a lock bit protection that locks all memory configuration registers. The memory configuration lock can be set by BIOS on boot.

If such a system also supports a low power sleep state like hibernate, the DRAM data must be saved in disk and restored when system resumes from hibernate. During hibernate, system DRAM would be powered off.

To support hibernate power transition flow, the DRAM memory configuration must be reprogrammed even though it was locked previously. During hibernate resume, the memory configuration could be modified or memory lock cleared.

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 same state as before entry to hibernate mode.

+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

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

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-01-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1259: Improper Protection of Security Identifiers

Weakness ID: 1259
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product 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 improperly protected.
+ Extended Description

Systems-On-Chip (Integrated circuits and hardware engines) implement Security Identifiers to differentiate/identify actions originated from various agents. These actions could be ‘read’, ‘write’, ‘program’, ‘reset’, ‘fetch’, ‘compute’, etc. Security identifiers are assigned to every agent in the System that is either capable of generating an action or receiving an action from other agent. Every agent could be assigned a unique Security Identifier based on its trust level or privileges. Since the Security Identifiers are very important to achieve security in SoC, they should be protected properly. A common weakness that can exist is that the Security Identifiers are improperly protected. Consequently, the Security Identifier can be programmed by a malicious agent (i.e., the Security Identifier is mutable) to spoof the action as if it originated from a trusted agent.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1254Incorrect Comparison Logic Granularity
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1270Generation of Incorrect Security Identifiers
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design phases.
ImplementationSuch issues could be introduced during implementation and identified later during testing or system configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Processor IP Class: Technology-Independent (Undetermined Prevalence)

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

High
+ Demonstrative Examples

Example 1

For example, consider a system with a register for storing AES key for encryption or decryption. The key is of 128 bits 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 with a security identifier in the transaction can access the AES-key registers. Each bit in this 32-bit register defines a security identifier. There could be a maximum of 32 security identifiers 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 Identifiers are “1” and “2”.

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

An agent with Security Identifier “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 identifier is “1”.

(bad code)
Example Language: Other 
The Aux-controller could program its Security Identifier to “1” from “2”.

The SoC does not properly protect the Security Identifier 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 access-controlled, AES-Key registers) by programming its Security Identifier to that of an agent that has access to the asset.

(good code)
Example Language: Other 
The SoC should protect the Security Identifiers. None of the agents in the SoC should have the ability to change the Security Identifier.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

  • Protection of Security Identifiers must be reviewed for design inconsistency and common weaknesses.
  • Security-Identifier definition and programming flow must be tested in pre-silicon and post-silicon testing.
+ Notes

Maintenance

This entry is still in 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-03-06Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1224: Improper Restriction of Write-Once Bit Fields

Weakness ID: 1224
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.
+ Extended Description

Integrated 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".

+ Relationships

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

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

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

PhaseNote
Architecture and Design
ImplementationSuch issues could be introduced during implementation of hardware design, since IP parameters and defaults are defined in HDL code and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Varies by Context

System configuration cannot be programmed in a secure way.
+ Demonstrative Examples

Example 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

Phase: Architecture and Design

During hardware design all register write-once or sticky fields must be evaluated for proper configuration.

Phase: Testing

The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1266: Improper Scrubbing of Sensitive Data from Decommissioned Device

Weakness ID: 1266
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Extended Description

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.404Improper Resource Shutdown or Release
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1195Manufacturing and Life Cycle Management Concerns
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

+ Potential Mitigations

Phase: Architecture and Design

Functionality to completely scrub data from a product at the conclusion of its lifecycle should be part of the design phase. Trying to add this function on top of an existing architecture could lead to incomplete removal of sensitive information/data.

Phase: Policy

The manufacturer should describe where sensitive data will be written to. For example, this information may be conveyed to the consumer in an Administrators Guide or a Statement of Volatility. The manufacturer should also describe the procedure which may be followed to remove this sensitive data.

Phase: Implementation

If the capability to wipe sensitive data isn't built-in, the manufactuerer may need to provide a utility to scrub sensitive data from storage if that data is located in a place which is non-accessible by the administrator. One example of this could be when sensitive data is stored on an EEPROM for which there is no user/admin interface provided by the system.

+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ References
[REF-1080] Christopher Tarnovsky. "Security Failures in Secure Devices". <https://www.blackhat.com/presentations/bh-europe-08/Tarnovsky/Presentation/bh-eu-08-tarnovsky.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-28Paul A. WortmanWells Fargo

CWE-1246: Improper Write Handling in Limited-write Non-Volatile Memories

Weakness ID: 1246
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product does not implement or incorrectly handles the implementation of write operations in limited-write non-volatile memories.
+ Extended Description

Non-volatile memories such as NAND Flash, EEPROM, etc. have individually erasable segments, each of which can be put through a limited number of program/erase or write cycles. For example, the device can only endure a limited number of writes, after which the device becomes unreliable. In order to wear out the cells in a uniform manner, non-volatile memory and storage products based on the above-mentioned technologies implement a technique called wear leveling. Once a set threshold is reached, wear leveling maps writes of a logical block to a different physical block. This prevents a single physical block from prematurely failing due to a high concentration of writes. If wear leveling is improperly implemented, attackers can execute a write virus and cause the storage to become unreliable much faster than the minimally guaranteed platform lifetime.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.664Improper Control of a Resource Through its Lifetime
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

Memory IP (Undetermined Prevalence)

Storage IP (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Availability

Technical Impact: DoS: Instability

+ Demonstrative Examples

Example 1

An adversary can render a memory line unusable by writing to it repeatedly.

Below is example code from [REF-1058] that the user can execute repeatedly to cause line failure. W is the maximum associativity of any cache in the system; S is the size of the largest cache in the system.

(bad code)
Example Language: Other 
Do aligned alloc of (W+1) arrays each of size S
while(1) {
for (ii = 0; i < W + 1; ii++)
array[ii].element[0]++;
}

Without wear leveling, the above attack will be successful. Simple randomization of blocks will not suffice as instead of the original physical block, the randomized physical block will be worn out.

(informative)
 
Wear leveling must be used to even out writes to the device.
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

Include secure wear leveling algorithms and ensure that it cannot be bypassed by known write viruses.

Effectiveness: High

+ References
[REF-1058] Moinuddin Qureshi, Michele Franchescini, Vijayalakshmi Srinivasan, Luis Lastras, Bulent Abali and John Karidis. "Enhancing Lifetime and Security of PCM-Based Main Memory with Start-Gap Wear Leveling". <https://researcher.watson.ibm.com/researcher/files/us-moinqureshi/papers-sgap.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1242: Inclusion of Undocumented Features or Chicken Bits

Weakness ID: 1242
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The chip includes chicken bits or undocumented features that can create entry points for unauthorized actors.
+ Extended Description

A common design practice is to use "chicken bits," which are bits on a chip that can be used to disable certain functional security features. They can facilitate quick identification and isolation of faulty components, features that negatively affect performance, or features that do not provide the required controllability for debug and test. Another way to achieve this is through implementation of undocumented features. An attacker might exploit these interfaces for unauthorized access.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

+ Demonstrative Examples

Example 1

Consider a chip that comes with various, security measures, such as secure boot. The secure-boot process performs firmware-integrity verification at boot time, and this code is stored in a separate SPI-flash chip. However, this code contains undocumented "special access features" intended to be used for performing failure analysis and can only be unlocked by the chip designer.

(bad code)
Example Language: Other 
Attackers dump the code from the chip and then perform reverse engineering to analyze the code. The undocumented, special-access features are identified, and attackers can activate them by sending specific commands via UART before secure-boot phase completes. Using these hidden features, attackers can perform reads and writes to memory via the UART interface. At runtime, the attackers can also execute arbitrary code and dump the entire memory contents.

Remove all chicken bits and hidden features that are exposed to attackers. Add authorization schemes that rely on cryptographic primitives to access any features that the manufacturer does not want to expose. Clearly document all interfaces.

+ Potential Mitigations

Phases: Architecture and Design; Implementation

Do not implement chicken bits. If implemented, ensure that they are disabled in production devices. Document all interfaces to the chip.

Effectiveness: High

+ References
[REF-1071] Ali Abbasi, Tobias Scharnowski and Thorsten Holz. "Doors of Durin: The Veiled Gate to Siemens S7 Silicon". <https://i.blackhat.com/eu-19/Wednesday/eu-19-Abbasi-Doors-Of-Durin-The-Veiled-Gate-To-Siemens-S7-Silicon.pdf>.
[REF-1072] Sergei Skorobogatov and Christopher Woods. "Breakthrough Silicon Scanning Discovers Backdoor in Military Chip". <https://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf>.
[REF-1073] Chris Domas. "God Mode Unlocked: Hardware Backdoors in x86 CPUs". <https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs.pdf>.
[REF-1074] Jonathan Brossard. "Hardware Backdooring is Practical". <https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf>.
[REF-1075] Sergei Skorabogatov. "Security, Reliability, and Backdoors". <https://www.cl.cam.ac.uk/~sps32/SG_talk_SRB.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-13Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1254: Incorrect Comparison Logic Granularity

Weakness ID: 1254
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
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.
+ Extended Description

Comparison logic is used to compare a variety of objects including passwords, Message Authentication Codes (MACs), and responses to verification challenges. When comparison logic is implemented at a finer granularity (e.g., byte-by-byte comparison) and breaks in the case of a comparison failure, an attacker can exploit this implementation to identify when exactly the failure occurred. With multiple attempts, the attacker may be able to guesses the correct password/response to challenge and elevate their privileges.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.697Incorrect Comparison
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.208Observable Timing Discrepancy
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1259Improper Protection of Security Identifiers
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1261Improper Handling of Single Event Upsets
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Authorization

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Consider an example hardware module that checks a user-provided password to grant access to a user. The user-provided password is compared against a golden value in a byte-by-byte manner.

(bad code)
Example Language: Other 
always_comb @ (posedge clk)
begin
assign check_pass[3:0] = 4’b0;
for (i = 0; i < 4; i++) begin
if (entered_pass[(i*8 – 1) : i] eq golden_pass([i*8 -1) : i])
assign check_pass[i] = 1;
continue;
else
assign check_pass[i] = 0;
break;
end
assign grant_access = (check_pass == 4’b1111) ? 1’b1: 1’b0;
end

Since the code breaks on an incorrect entry of password, an attacker can guess the correct password for that byte-check iteration with few repeat attempts.

(informative)
 

Either the comparison of the entire string should be done all at once or the attacker is not given an indication whether pass or fail happened by allowing the comparison to run through all bits before the grant_access signal is set.

always_comb @ (posedge clk)

begin
assign check_pass[3:0] = 4’b0;
for (i = 0; i < 4; i++) begin
if (entered_pass[(i*8 – 1) : i] eq golden_pass([i*8 -1) : i])
assign check_pass[i] = 1;
continue;
else
assign check_pass[i] = 0;
continue;
end
assign grant_access = (check_pass == 4’b1111) ? 1’b1: 1’b0;
end
+ Observed Examples
ReferenceDescription
The passwordCheck function in SAP Router 721 patch 117, 720 patch 411, 710 patch 029, and earlier terminates validation of a Route Permission Table entry password upon encountering the first incorrect character, which allows remote attackers to obtain passwords via a brute-force attack that relies on timing differences in responses to incorrect password guesses, aka a timing side-channel attack.
+ Potential Mitigations

Phase: Implementation

The hardware designer should ensure that comparison logic is implemented so as to compare in one operation instead in smaller chunks.

+ References
[REF-1079] Joe Fitzpatrick. "SCA4n00bz - Timing-based Sidechannel Attacks for Hardware N00bz workshop". <https://github.com/securelyfitz/SCA4n00bz>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-276: Incorrect Default Permissions

Weakness ID: 276
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.732Incorrect Permission Assignment for Critical Resource
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.732Incorrect Permission Assignment for Critical Resource
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Modes Of Introduction

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

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Installation
Operation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Likelihood Of Exploit
Medium
+ Observed Examples
ReferenceDescription
Executables installed world-writable.
Home directories installed world-readable.
World-writable log files allow information loss; world-readable file has cleartext passwords.
World-readable directory.
Windows product uses insecure permissions when installing on Solaris (genesis: port error).
Insecure permissions for a shared secret key file. Overlaps cryptographic problem.
Default permissions of a device allow IP spoofing.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges.

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

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Inter-application Flow Analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Host Application Interface Scanner
Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer
  • Automated Monitored Execution
  • Forced Path Execution

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsecure Default Permissions
CERT C Secure CodingFIO06-CCreate files with appropriate access permissions
The CERT Oracle Secure Coding Standard for Java (2011)FIO01-JCreate files with appropriate access permission
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Insecure Defaults", Page 69. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Insecure Default Permissions

CWE-1221: Incorrect Register Defaults or Module Parameters

Weakness ID: 1221
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Hardware description language code incorrectly defines register defaults or hardware IP parameters to insecure values.
+ Extended Description

Integrated 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 defined default values that are hard coded in the hardware description language (HDL) code of the hardware unit. Hardware descriptive languages also support definition of parameter variables, which can be defined in code during instantiation of the hardware IP module. Such parameters are generally used to configure a specific instance of a hardware IP in the design.

The system security settings of a hardware design can be affected by incorrectly defined default values or IP parameters. The hardware IP would be in an insecure state at power reset, and this can be exposed or exploited by untrusted software running on the system. Both register defaults and parameters are hardcoded values, which cannot be changed using software or firmware patches but must be changed in hardware silicon. Thus, such security issues are considerably more difficult to address later in the lifecycle. Hardware designs can have a large number of such parameters and register defaults settings, and it is important to have design tool support to check these settings in an automated way and be able to identify which settings are security sensitive.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.665Improper Initialization
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

PhaseNote
ImplementationSuch issues could be introduced during implementation of hardware design, since IP parameters and defaults are defined in HDL code and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Varies by Context

Degradation of system functionality, or loss of access control enforcement
+ Demonstrative Examples

Example 1

Consider example design module system verilog code shown below.register_example module is an example parameterized module that defines two parameters, REGISTER_WIDTH and REGISTER_DEFAULT. Register_example module defines a Secure_mode setting, which when set makes the register content read-only and not modifiable by software writes. register_top module instantiates two registers, Insecure_Device_ID_1 and Insecure_Device_ID_2. Generally, registers containing device identifier values are required to be read only to prevent any possibility of software modifying these values.

(bad code)
Example Language: Verilog 
// Parameterized Register module example
// Secure_mode : REGISTER_DEFAULT[0] : When set to 1 register is read only and not writable//
/module register_example
s#(
parameter REGISTER_WIDTH = 8, // Parameter defines width of register, default 8 bits
parameter [REGISTER_WIDTH-1:0] REGISTER_DEFAULT = 2**REGISTER_WIDTH -2 // Default value of register computed from Width. Sets all bits to 1s except bit 0 (Secure _mode)
)
(
input [REGISTER_WIDTH-1:0] Data_in,
input Clk,
input resetn,
input write,
output reg [REGISTER_WIDTH-1:0] Data_out
);

reg Secure_mode;

always @(posedge Clk or negedge resetn)
if (~resetn)
begin
Data_out <= REGISTER_DEFAULT; // Register content set to Default at reset
Secure_mode <= REGISTER_DEFAULT[0]; // Register Secure_mode set at reset
end
else if (write & ~Secure_mode)
begin
Data_out <= Data_in;
end
endmodule


module register_top
(
input Clk,
input resetn,
input write,
input [31:0] Data_in,
output reg [31:0] Secure_reg,
output reg [31:0] Insecure_reg
);

register_example #(
.REGISTER_WIDTH (32),
.REGISTER_DEFAULT (1224) // Incorrect Default value used bit 0 is 0.
) Insecure_Device_ID_1 (
.Data_in (Data_in),
.Data_out (Secure_reg),
.Clk (Clk),
.resetn (resetn),
.write (write)
);

register_example #(
.REGISTER_WIDTH (32) // Default not defined 2^32-2 value will be used as default.
) Insecure_Device_ID_2 (
.Data_in (Data_in),
.Data_out (Insecure_reg),
.Clk (Clk),
.resetn (resetn),
.write (write)
);

endmodule

These example instantiations show how, in a hardware design, it would be possible to instantiate the register module with insecure defaults and parameters.

In the example design, both registers will be software writable since Secure_mode is defined as zero.

(informative)
 
register_example #(
.REGISTER_WIDTH (32),
.REGISTER_DEFAULT (1225) // Correct default value set, to enable Secure_mode
) Secure_Device_ID_example (
.Data_in (Data_in),
.Data_out (Secure_reg),
.Clk (Clk),
.resetn (resetn),
.write (write)
);
+ Potential Mitigations

Phase: Architecture and Design

During hardware design, all the system parameters and register defaults must be reviewed to identify security sensitive settings.

Phase: Implementation

The default values of these security sensitive settings need to be defined as part of the design review phase.

Phase: Testing

Testing phase should use automated tools to test that values are configured per design specifications.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-12Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1253: Incorrect Selection of Fuse Values

Weakness ID: 1253
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The logic used to determine system-security state for the product relies on values sensed from the fuses, but it relies on 'negative' logic for an un-blown fuse.
+ Extended Description

Fuses are often used to store secret data, including security configuration data. When not blown, a fuse is considered to store a logic 0, and, when blown, it indicates a logic 1. Fuses are generally considered to be one-directional, i.e., once blown to logic 1, it cannot be reset to logic 0. However, if the logic used to determine system-security state (by leveraging the values sensed from the fuses) uses negative logic, an attacker might blow the fuse and drive the system to an unsecure state.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.693Protection Mechanism Failure
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1199General Circuit and Logic Design Concerns
+ Modes Of Introduction

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control
Authorization

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

Availability

Technical Impact: DoS: Crash, Exit, or Restart

Confidentiality

Technical Impact: Read Memory

Integrity

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

A chip implements secure boot and uses the sensed value of the fuse “do_secure_boot” to determine whether to perform secure boot or not. If this fuse value is “0”, the system performs secure boot. Otherwise, it does not perform secure boot. An attacker blows the "do_secure_boot" fuse to “1”. After reset, attacker loads custom bootloader, and, since the fuse value is now “1”, the system does not perform secure boot, and attacker can execute custom firmware image. Since the default, fuse-configuration value is 0, an attacker can blow it to 1 with inexpensive hardware. If the logic is reversed, then an attacker cannot reset the fuse. Note that, with specialized and expensive equipment, an attacker might be able to reset the fuse value to 0.

+ Potential Mitigations

Phase: Architecture and Design

Logic should be designed in a way that blown fuses do not put the product into an insecure state that can be leveraged by an attacker.

+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ References
[REF-1080] Christopher Tarnovsky. "Security Failures in Secure Devices". <https://www.blackhat.com/presentations/bh-europe-08/Tarnovsky/Presentation/bh-eu-08-tarnovsky.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-10-15Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1220: Insufficient Granularity of Access Control

Weakness ID: 1220
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Extended Description

Integrated circuits and hardware engines can expose accesses to assets (device configuration, keys, etc.) to trusted firmware or a software module (commonly set by BIOS/bootloader). This access is typically access-controlled. Upon a power reset, the hardware or system usually starts with default values in registers, and the trusted firmware (Boot firmware) configures the necessary access-control protection.

A common weakness that can exist in such protection schemes is that access controls or policies are not granular enough. This condition allows agents beyond trusted agents to access assets and could lead to a loss of functionality or the ability to set up the device securely. This further results in security risks from leaked, sensitive, key material to modification of device configuration.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
ParentOfVariantVariant - 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.1222Insufficient Granularity of Address Regions Protected by Register Locks
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignSuch issues could be introduced during hardware architecture and design and identified later during Testing or System Configuration phases.
ImplementationSuch issues could be introduced during hardware implementation and identified later during Testing or System Configuration phases.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

High
+ Demonstrative Examples

Example 1

Consider a system with a register for storing AES key for encryption or decryption. The key is 128 bits, implemented as a set of four 32-bit registers. The key registers are assets and registers, AES_KEY_READ_POLICY and AES_KEY_WRITE_POLICY, and are defined to provide necessary access controls.

The read-policy register defines which agents can read the AES-key registers, and write-policy register defines which agents can program or write to those registers. Each register is a 32-bit register, and it can support access control for a maximum of 32 agents. 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.

(bad code)
Example Language: Other 
Register Field description
AES_ENC_DEC_KEY_0 AES key [0:31] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_1 AES key [32:63] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_2 AES key [64:95] for encryption or decryption
Default 0x00000000
AES_ENC_DEC_KEY_4 AES key [96:127] for encryption or decryption
Default 0x00000000
AES_KEY_READ_WRITE_POLICY [31:0] Default 0x00000006 - meaning agent with identities "1" and "2" can both read from and write to key registers

In the above example, there is only one policy register that controls access to both read and write accesses to the AES-key registers, and thus the design is not granular enough to separate read and writes access for different agents. Here, agent with identities "1" and "2" can both read and write.

A good design should be granular enough to provide separate access controls to separate actions. Access control for reads should be separate from writes. Below is an example of such implementation where two policy registers are defined for each of these actions. The policy is defined such that: the AES-key registers can only be read or used by a crypto agent with identity "1" when bit #1 is set. The AES-key registers can only be programmed by a trusted firmware with identity "2" when bit #2 is set.

(mitigation)
 
AES_KEY_READ_POLICY [31:0] Default 0x00000002 - meaning only Crypto engine with identity "1" can read registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3
AES_KEY_WRITE_POLICY [31:0] Default 0x00000004 - meaning only trusted firmware with identity "2" can program registers: AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, AES_ENC_DEC_KEY_3
+ Potential Mitigations

Phases: Architecture and Design; Implementation; Testing

  • Access-control-policy protections must be reviewed for design inconsistency and common weaknesses.
  • Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.

Effectiveness: High

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-05Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-1263: Insufficient Physical Protection Mechanism

Weakness ID: 1263
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product is designed such that certain parts be restricted yet does not sufficiently protect against an unauthorized actor’s ability to physically access these restricted regions of the product.
+ Extended Description

Sections of a product intended as restricted may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.693Protection Mechanism Failure
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1191Exposed Chip Debug and or Test Interface With Insufficient Access Control
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1243Exposure of Security-Sensitive Fuse Values During Debug
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignThis weakness can arise if design decisions are made that do not align with the intended physical protection of the product
ManufacturingWhile the design phase of the lifecycle may have accurately met the intented robustness for product physical protections, this phase may introduce the weakness through errors in physically manufacturing the product.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Varies by Context

Confidentiality, Integrity, and Access Control of product internals may result in a variety of negative outcomes and lead to numerous further compromise to system security.
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Testing

The testing phase of the lifecycle should establish a method for determining whether the physical protection mechanism levered for preventing unauthorized access to certain sections or parts of the product.

Phase: Manufacturing

+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-28CWE Content TeamMITRE

CWE-1274: Insufficient Protections on the Volatile Memory Containing Boot Code

Weakness ID: 1274
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Extended Description

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.284Improper Access Control
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1196Security Flow Issues
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignThis weakness can be introduced during hardware architecture or design but can be identified later during testing.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Authentication

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

High
+ Demonstrative Examples

Example 1

A typical SoC secure boot’s flow includes fetching the next piece of code (i.e., the boot loader) from NVM (e.g., serial, peripheral interface (SPI) flash), and transferring it to DRAM/SRAM volatile, internal memory. The advantage of using DRAM/SRAM is that the access time is faster and cheaper per byte than NVM.

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

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

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

Phase: Architecture and Design

During this phase, ensure that the design of volatile-memory protections are enough to prevent modification from an adversary or untrusted code.

Phase: Testing

Test the volatile-memory protections to ensure they are safe from modification or untrusted code.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-04-25Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE CATEGORY: Integration Issues

Category ID: 1197
Status: Draft
+ Summary
Weaknesses in this category are those that arise due to integration of multiple hardware Intellectual Property (IP) cores from third parties, or from the prior generation of products into a common System-on-Chip (SoC) or hardware platform.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1276Hardware Block Incorrectly Connected to Larger System
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: Manufacturing and Life Cycle Management Concerns

Category ID: 1195
Status: Draft
+ Summary
Weaknesses in this category are root-caused to defects that arise in the semiconductor-manufacturing process or during the life cycle and supply chain.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1248Semiconductor Defects in Hardware Logic with Security-Sensitive Implications
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1266Improper Scrubbing of Sensitive Data from Decommissioned Device
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1269Product Released in Non-Release Configuration
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1273Device Unlock Credential Sharing
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1278Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: Memory and Storage Issues

Category ID: 1202
Status: Draft
+ Summary
Weaknesses in this category are typically associated with memory (e.g., DRAM, SRAM) and storage technologies (e.g., NAND Flash, OTP, EEPROM, and eMMC).
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1194Hardware Design
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.226Sensitive Information Uncleared in Resource Before Release for Reuse
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1246Improper Write Handling in Limited-write Non-Volatile Memories
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1251Mirrored Regions with Different Values
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1257Improper Access Control Applied to Mirrored or Aliased Memory Regions
HasMemberBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1282Assumed-Immutable Data Stored in Writable Memory
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-12-27CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-06-25CWE Content TeamMITRE
updated Relationships

CWE-1251: Mirrored Regions with Different Values

Weakness ID: 1251
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product's architecture mirrors regions without ensuring that their contents always stay in sync.
+ Extended Description

Having mirrored regions with different values might result in the exposure of sensitive information and/or other consequences, including loss of access control.

Due to architectural and performance constraints, one might need to duplicate a resource. The most common example of doing this in computer architecture is the concept of cache, which keeps a "local" copy of the data element in memory, because the time to access the memory (which is located far off from the computing core) is significantly longer compared to the time it takes to access a local copy (cache). Thus, keeping a local copy of some distant entity provides significant performance improvement. Unfortunately, this improvement also comes with a downside, since the product needs to ensure that the local copy always mirrors the original copy truthfully. If they get out of sync somehow, the computational result is no longer true.

In designing hardware, memory is not the only thing that gets mirrored. There are many other entities that get mirrored, too: registers, memory regions, and, in some cases, even whole units. For example, for a multi-core processor, if every memory access from any of those tens of cores goes through a single memory-management unit (MMU) for security reasons, then the MMU becomes a performance bottleneck. In such cases, it might make sense to create duplicate, local MMUs that will serve only a subset of the cores of processors rather than all of them. These local copies are also called "shadow copies" or "mirrored copies."

If the original resource that was being duplicated into these local copies never changed, the question of the local copies getting out of sync would not arise. Unfortunately, in many cases, the values inside the original copy change. For example, a memory range might be inaccessible during boot time, but once the boot process is over and the system is now in a stable state, that memory range may now be opened up for access. So, if a register(s) in the access-control unit stores the start and end addresses of the "accessible" memory chunks, those values would change after the boot process is over. Now, when the original copy changes, the mirrored copies must also change, and change fast.

This situation of shadow-copy-possibly-out-of-sync-with-original-copy might occur as a result of multiple scenarios, including the following:

  • After the values in the original copy change, due to some reason the original copy does not send the "update" request to its shadow copies.
  • After the values in the original copy change, the original copy dutifully sends the "update" request to its shadow copies, but due to some reason the shadow copy does not "execute" this update request.
  • After the values in the original copy change, the original copy sends the "update" request to its shadow copies, and the shadow copy executes this update request faithfully. However, during the small time period when the original copy has "new" values and the shadow copy is still holding the "old" values, an attacker can exploit the old values. Then it becomes a race condition between the attacker and the update process of who can reach the target, shadow copy first, and, if the attacker reaches first, the attacker wins.
  • The attacker might send a "spoofed" update request to the target shadow copy, pretending that this update request is coming from the original copy. This spoofed request might cause the targeted shadow copy to update its values to some attacker-friendly values, while the original copies remain unchanged by the attacker.
  • Suppose a situation where the original copy has a system of reverting back to its original value if it does not hear back from all the shadow copies that such copies have successfully completed the update request. In such a case, an attack might occur as follows: (1) the original copy might send an update request; (2) the shadow copy updates it; (3) the shadow copy sends back the successful completion message; (4) through a separate issue, the attacker is able to intercept the shadow copy's completion message. In this case, the original copy thinks that the update did not succeed, hence it reverts to its original value. Now there is a situation where the original copy has the "old" value, and the shadow copy has the "new" value.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1250Improper Preservation of Consistency Between Independent Representations of Shared State
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

VHDL (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Security IP (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.

+ Potential Mitigations

Phase: Architecture and Design

Whenever there are multiple, physically different copies of the same value that might change and the process to update them is not instantaneous and atomic, it is impossible to assert that the original and shadow copies will always be in sync - there will always be a time period when they are out of sync. To mitigate the consequential risk, the recommendations essentially are:

  • Make this out-of-sync time period as small as possible, and
  • Make the update process as robust as possible.

Effectiveness: Moderate

+ Notes

Research Gap

Issues related to state and cache - creation, preservation, and update - are a significant gap in CWE that is expected to be addressed in future versions. It likely has relationships to concurrency and synchronization, incorrect behavior order, and other areas that already have some coverage in CWE, although the focus has typically been on independent processes on the same operating system - not on independent systems that are all a part of a larger system-of-systems.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation

CWE-1053: Missing Documentation for Design

Weakness ID: 1053
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product does not have documentation that represents how it is designed.
+ Extended Description

This issue can make it more difficult to understand and maintain the product. It can make it more difficult and time-consuming to detect and/or fix vulnerabilities.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.1059Incomplete Documentation
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1225Documentation Issues
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ References
[REF-963] Robert A. Martin and Lawrence H. Shafer. "Providing a Framework for Effective Software Quality Assessment". 1996-07. <https://www.researchgate.net/publication/285403022_PROVIDING_A_FRAMEWORK_FOR_EFFECTIVE_SOFTWARE_QUALITY_MEASUREMENT_MAKING_A_SCIENCE_OF_RISK_ASSESSMENT>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships

CWE-1271: Missing Known Value on Reset for Registers Holding Security Settings

Weakness ID: 1271
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The product's logic for state elements that implement security-critical functionality does not have a mechanism for being initialized to a known value on reset.
+ Extended Description

When a circuit is first brought out of reset, the state of storage elements will be unknown if not explicitly initialized by the logic. If registers holding security-critical state are not properly initialized before being used to control access to design assets or critical resources, there will be a timing window during which the device is in an insecure state and vulnerable to attack.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.665Improper Initialization
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1206Power, Clock, and Reset Concerns
+ Modes Of Introduction

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

PhaseNote
ImplementationThis weakness can be manifest during this phase if registers that hold security-critical state are not implemented to initialize to a secure value upon reset.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control
Authentication
Authorization

Technical Impact: Varies by Context

The attacker may gain access to some resources if the state of the access control circuitry is not set to a known value on reset.
+ Demonstrative Examples

Example 1

Shown below is a positive clock edge triggered flip-flop used to implement a lock bit for the test and debug interface. When the circuit is first brought out of reset, the state of the storage element will be unknown until the enable and d-input signals update the stored value. In this example, an attacker can reset the device until the test and debug interface is unlocked and access the test interface until the lock signal is driven to a known state by the logic.

(bad code)
Example Language: Other 
always @(posedge clk) begin
if (en) lock_jtag <= d;
end

The flip-flop can be set to a known value (0 or 1) on reset, but requires that the logic explicitly update the output of the flip-flop if the reset signal is active.

(good code)
Example Language: Other 
always @(posedge clk) begin
if (~reset) lock_jtag <= 0;
else if (en) lock_jtag <= d;
end
+ Potential Mitigations

Phase: Implementation

Perform design checks to identify any uninitialized flip-flops in the design to ensure none are security-critical.

Phase: Architecture and Design

All registers holding security-critical state should be set to a secure value explicitly on reset or carefully designed to ensure that the inputs of the register update the contents to a secure value before any downstream logic is affected by the security state.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-15Nicole FernTortuga Logic

CWE-1278: Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques

Weakness ID: 1278
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Secrets stored in hardware can be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
+ Extended Description

The physical structure of the hardware, if viewed at high enough magnification and resolution, can reveal the functionality and data stored inside. Typical steps in IC reverse engineering involve removing the chip packaging (decapsulation) then using various imaging techniques ranging from non-invasive (high resolution x-ray microscopy) to invasive techniques involving removing IC layers and imaging each layer using a scanning electron microscope.

The goal of such activities is to recover secret keys, unique device identifiers, and proprietary code and circuit designs embedded in hardware that the attacker has been unsuccessful at accessing through other means. These secrets may be stored in non-volatile memory or in the circuit netlist. Memory technologies such as masked ROM are easier to extract secrets from than One-time Programmable (OTP) memory.

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfPillarPillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.693Protection Mechanism Failure
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1195Manufacturing and Life Cycle Management Concerns
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting Problems
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignThis weakness can manifest during this phase if the designer fails to account for efforts to leverage IC imaging techniques to access unauthorized information within the product.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Varies by Context

A common goal of malicious actors who reverse engineer ICs is to produce and sell counterfeit versions of the IC.
+ Demonstrative Examples

Example 1

Consider a SoC design that embeds a secret key in read-only memory (ROM). The key is baked into the design logic itself meaning it cannot be modified after fabrication and is identical for all ICs. An attacker in possession of the IC can decapsulate and delayer the chip. After imaging the layers, computer vision algorithms or manual inspection of the circuit features can locate the ROM and reveal the value of the key bits as encoded in the visible circuit structure of the ROM.

+ Potential Mitigations

Phase: Architecture and Design

Cost of effort to extract secrets via IC reverse engineering should outweigh the potential value of the secrets being disclosed. Appropriate technologies should be chosen to store design secrets based on threat model and secret value. Examples include IC camoflaging and obfuscation, tamper-proof packaging, active shielding, and circuitry to erase sensitive data upon detection of physical tampering.
+ Notes

Maintenance

This entry is still under development and will continue to see updates and content improvements.
+ References
[REF-1092] Shahed E. Quadir, Junlin Chen, Domenic Forte, Navid Asadizanjani, Sina Shahbazmohamadi, Lei Wang, John Chandy and Mark Tehranipoor. "A Survey on Chip to System Reverse Engineering". <https://dl.acm.org/doi/pdf/10.1145/2755563>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-20Nicole FernTortuga Logic

CWE-1247: Missing Protection Against Voltage and Clock Glitches

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

A product might support security features such as secure boot that are supported through hardware and firmware implementation. This involves establishing a chain of trust, starting with an immutable root of trust by checking the signature of the next stage (culminating with the OS and runtime software) against a golden value before transferring control. The intermediate stages typically set up the system in a secure state by configuring several access control settings. Similarly, any password-checking logic for exercising the debug interface, etc. can implemented in hardware, firmware, or both. This implementation needs to be robust against fault attacks such as voltage glitches and clock glitches that an attacker may leverage to compromise the system.

+ Relationships

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

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

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

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

Power Management IP (Undetermined Prevalence)

Clock/Counter IP (Undetermined Prevalence)

Sensor IP (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

+ Demonstrative Examples

Example 1

Below is a representative snippet of C code that is part of the secure-boot flow. A signature of the runtime-firmware image is calculated and compared against the golden value. If the signatures match, the bootloader loads runtime firmware. If not, it is not loaded. If the underlying hardware executing this code does not contain any circuitry or sensors to detect voltage/clock glitches, an attacker might launch a fault-injection attack right when the signature check is happening (at the location marked with the comment), and it could bypass the signature-checking process.

(bad code)
Example Language: Other 
...

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

...

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

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

Phases: Architecture and Design; Implementation

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

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

CWE-325: Missing Required Cryptographic Step

Weakness ID: 325
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by that algorithm.
+ Extended Description
Cryptographic implementations should precisely follow the algorithms that define them, otherwise encryption can be weaker than expected.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.573Improper Following of Specification by Caller
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.358Improperly Implemented Security Check for Standard
+ Relevant to the view "Software Development" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
+ Modes Of Introduction

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

PhaseNote
Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Developers sometimes omit certain "expensive" (resource-intensive) steps in order to improve performance, especially in devices with limited memory or CPU cycles. This could be done under a mistaken impression that the step is unnecessary for preserving security. Alternately, the developer might adopt a threat model that is inconsistent with that of its consumers by accepting a risk for which the remaining protection seems "good enough."

Architecture and Design
Requirements

This issue can be introduced when the requirements for the algorithm are not clearly stated.

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

Languages

Class: Language-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

If the cryptographic algorithm is used for authentication and authorization, then an attacker could gain unauthorized access to the system.
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

Sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
Accountability
Non-Repudiation

Technical Impact: Hide Activities

If the cryptographic algorithm is used to ensure the identity of the source of the data (such as digital signatures), then a broken algorithm will compromise this scheme and the source of the data cannot be proven.
+ Observed Examples
ReferenceDescription
Missing challenge-response step allows authentication bypass using public key.
+ Functional Areas
  • Cryptography
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.719OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.720OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
+ Notes

Relationship

Overlaps incomplete/missing security check.

Relationship

Can be resultant.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Required Cryptographic Step
OWASP Top Ten 2007A8CWE More SpecificInsecure Cryptographic Storage
OWASP Top Ten 2007A9CWE More SpecificInsecure Communications