CWE-1221: Incorrect Register Defaults or Module Parameters

How it's found

Incorrect Register Defaults or Module Parameters 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.

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.

Vulnerable vs. safe

Data_out <= REGISTER_DEFAULT; // Register content set to Default at resetSecure_mode <= REGISTER_DEFAULT[0]; // Register Secure_mode set at reset

Data_out <= Data_in;if (~resetn)beginendelse if (write & ~Secure_mode)beginend

.REGISTER_WIDTH (32),.REGISTER_DEFAULT (1224) // Incorrect Default value used bit 0 is 0.

.Data_in (Data_in),.Data_out (Secure_reg),.Clk (Clk),.resetn (resetn),.write (write)

.REGISTER_WIDTH (32) // Default not defined 2^32-2 value will be used as default.

.Data_in (Data_in),.Data_out (Insecure_reg),.Clk (Clk),.resetn (resetn),.write (write)// 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 bitsparameter [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)endmodulemodule 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 #() Insecure_Device_ID_1 ();register_example #() Insecure_Device_ID_2 ();endmodule

.REGISTER_WIDTH (32),.REGISTER_DEFAULT (1225) // Correct default value set, to enable Secure_mode

.Data_in (Data_in),.Data_out (Secure_reg),.Clk (Clk),.resetn (resetn),.write (write)register_example #() Secure_Device_ID_example ();

Consequences

• Varies by Context: Degradation of system functionality, or loss of access control enforcement can occur.

Mitigations

• Architecture and Design: During hardware design, all the system parameters and register defaults must be reviewed to identify security sensitive settings.
• Implementation: The default values of these security sensitive settings need to be defined as part of the design review phase.

Where this fits in a TurboPentest engagement

This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.

Frequently asked questions

Related CWEs

• Class weakness
  CWE-1419: Incorrect Initialization of Resource