CWE-1221 — Vulnerability Class 2

2 vulnerabilities classified as CWE-1221. AI Chinese analysis included.

CWE-1221 represents a hardware design flaw where register defaults or Intellectual Property parameters are incorrectly initialized to insecure values. This weakness typically arises when hardware description language code fails to assign safe, predefined states to programmable controls during a hardware reset, leaving critical settings vulnerable to manipulation. Attackers can exploit this by altering register contents to bypass security mechanisms, escalate privileges, or cause system instability, effectively compromising the integrity of the integrated circuit. To mitigate this risk, developers must rigorously validate all default configurations during the design phase, ensuring that every register and IP parameter is explicitly set to a secure, hardened state. Comprehensive verification processes, including formal verification and extensive testing, are essential to confirm that hardware initialization sequences consistently enforce these secure defaults, thereby preventing unauthorized access or malicious control of the underlying hardware infrastructure.

MITRE CWE Description

Hardware description language code incorrectly defines register defaults or hardware Intellectual Property (IP) parameters to insecure values. 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.

Common Consequences (1)

Confidentiality, Integrity, Availability, Access ControlVaries by Context

Degradation of system functionality, or loss of access control enforcement can occur.

Mitigations (2)

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

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

Examples (2)

Consider example design module system verilog code shown below. The 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_Devi…

// Parameterized Register module example // Secure_mode : REGISTER_DEFAULT[0] : When set to 1 register is read only and not writable// module register_example #( 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 (~

Bad · Verilog

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) );

Good · Verilog

The example code is taken from the fuse memory inside the buggy OpenPiton SoC of HACK@DAC'21 [REF-1356]. Fuse memory can be used to store key hashes, password hashes, and configuration information. For example, the password hashes of JTAG and HMAC are stored in the fuse memory in the OpenPiton design.

parameter  MEM_SIZE = 100; localparam JTAG_OFFSET = 81; const logic [MEM_SIZE-1:0][31:0] mem = { // JTAG expected hamc hash 32'h49ac13af, 32'h1276f1b8, 32'h6703193a, 32'h65eb531b, 32'h3025ccca, 32'h3e8861f4, 32'h329edfe5, 32'h98f763b4, ... assign jtag_hash_o = {mem[JTAG_OFFSET-1],mem[JTAG_OFFSET-2],mem[JTAG_OFFSET-3], mem[JTAG_OFFSET-4],mem[JTAG_OFFSET-5],mem[JTAG_OFFSET-6],mem[JTAG_OFFSET-7],mem[JTAG_OFFSET-8]}; ...

Bad · Verilog

parameter  MEM_SIZE = 100; localparam JTAG_OFFSET = 100;

Good · Verilog

CVE ID	Title	CVSS	Severity	Published
CVE-2022-20731	Cisco Catalyst Digital Building Series Switches and Cisco Catalyst Micro Switches Vulnerabilities — Cisco IOS ROMMON Software	4.6	Medium	2022-04-15
CVE-2022-20661	Cisco Catalyst Digital Building Series Switches and Cisco Catalyst Micro Switches Vulnerabilities — Cisco IOS ROMMON Software	4.6	Medium	2022-04-15

Vulnerabilities classified as CWE-1221 represent 2 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.

Goal Reached Thanks to every supporter — we hit 100%!

CWE-1221 — Vulnerability Class 2