CWE-1419: Incorrect Initialization of Resource

Intro: 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_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.

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

// 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 (~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

Intro: This code attempts to login a user using credentials from a POST request:

Body: Because the $authorized variable is never initialized, PHP will automatically set $authorized to any value included in the POST request if register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials.

// $user and $pass automatically set from POST request if (login_user($user,$pass)) { $authorized = true; } ... if ($authorized) { generatePage(); }

Intro: The following example code is excerpted from the Access Control module, acct_wrapper, in the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Within this module, a set of memory-mapped I/O registers, referred to as acct_mem, each 32-bit wide, is utilized to store access control permissions for peripherals [REF-1437]. Access control registers are typically used to define and enforce permissions and access rights for various system resources.

Body: However, in the buggy SoC, these registers are all enabled at reset, i.e., essentially granting unrestricted access to all system resources [REF-1438]. This will introduce security vulnerabilities and risks to the system, such as privilege escalation or exposing sensitive information to unauthorized users or processes.

module acct_wrapper #( ... always @(posedge clk_i) begin if(~(rst_ni && ~rst_6)) begin for (j=0; j < AcCt_MEM_SIZE; j=j+1) begin acct_mem[j] <= 32'hffffffff; end end ...