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

How it's found

Hardware Internal or Debug Modes Allow Override of Locks is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.

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

Vulnerable vs. safe

lock_status <= 1'b0;

lock_status <= 1'b1;

lock_status <= lock_statusif (~resetn) // Register is reset resetnbeginendelse if (Lock)beginendelse if (~Lock)beginend

Data_out <= 16'h0000;

Data_out <= Data_in;

Data_out <= Data_out;if (~resetn) // Register is reset resetnbeginendelse if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported for scan_mode & debug_unlockedbeginendelse if (~write)beginendmodule 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)always @(posedge Clk or negedge resetn)endmodule

Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized users may enable these modes.

Consequences

• Bypass Protection Mechanism: Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.

Mitigations

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

Where this fits in a TurboPentest engagement

TurboPentest's agentic pentest is powerful and covers a broad range of issues automatically. This particular class is best confirmed in a manual IntegSec engagement, where human pentesters apply deeper methodology and a larger context window than any automated pass.

Frequently asked questions

Related CWEs

• Class weakness
  CWE-667: Improper Locking