logo

Hardware Internal or Debug Modes Allow Override of Locks

Incomplete Base
Structure: Simple
Description

Hardware debug modes or internal states can bypass critical system lock protections, allowing unauthorized changes to device configuration.

Extended Description

Many hardware systems use a lock bit—often set by trusted firmware like a BIOS or bootloader during startup—to permanently protect crucial configuration registers. Once this lock is engaged, it should prevent any further modification to settings that control system security, such as memory protection units. However, if the hardware design includes special debug modes or internal testing states, these privileged pathways can sometimes override the lock, defeating its primary purpose. This creates a significant vulnerability because an attacker with access to these debug features can alter foundational system configurations after they were supposedly locked down. Developers must ensure that hardware lock mechanisms are truly immutable and that all debug and test modes are thoroughly assessed and disabled before deployment to prevent such overrides.
Common Consequences 1
Scope: Access Control

Impact: Bypass Protection Mechanism

Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.
Potential Mitigations 1
Phase: Architecture and DesignImplementationTesting
- 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.

Effectiveness: High
Demonstrative Examples 2
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.

Code Example:

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

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

Code Example:

Good

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.

The following example code [REF-1375] is taken from the register lock security peripheral of the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These reglk_mem registers are reset when the hardware powers up and configured during boot up. Malicious users, even with kernel-level software privilege, do not get access to the sensitive contents that are locked down. Hence, the security of the entire system can potentially be compromised if the register lock configurations are corrupted or if the register locks are disabled.

Code Example:

Bad
Verilog

... always @(posedge clk_i)

verilog

if(~(rst_ni && ~jtag_unlock && ~rst_9))**

verilog

...

The example code [REF-1375] illustrates an instance of a vulnerable implementation of register locks in the SoC. In this flawed implementation [REF-1375], the reglk_mem registers are also being reset when the system enters debug mode (indicated by the jtag_unlock signal). Consequently, users can simply put the processor in debug mode to access sensitive contents that are supposed to be protected by the register lock feature.
This can be mitigated by excluding debug mode signals from the reset logic of security-critical register locks as demonstrated in the following code snippet [REF-1376].
Code Example:
Good
Verilog
...
always @(posedge clk_i)


verilog


if(~(rst_ni && ~rst_9))**


verilog


...


    
References 2
reglk_wrapper.sv
2021
https://github.com/HACK-EVENT/hackatdac21/blob/cde1d9d6888bffab21d4b405ccef61b19c58dd3c/piton/design/chip/tile/ariane/src/reglk/reglk_wrapper.sv#L80C1-L80C48(2023-12-13)
ID: REF-1375
Fix for reglk_wrapper.sv
2021
https://github.com/HACK-EVENT/hackatdac21/blob/20238068b385d7ab704cabfb95ff95dd6e56e1c2/piton/design/chip/tile/ariane/src/reglk/reglk_wrapper.sv#L80(2023-12-13)
ID: REF-1376
 
  
    
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
 
 
Technologies:
 
 
 Not Technology-Specific : Undetermined 
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Architecture and Design  
 
  Implementation  
 
 
 
  
Related Attack Patterns 
        
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Improper Locking (CWE-667)