CWE - CWE-1419: Incorrect Initialization of Resource (4.17)

Weakness ID: 1419

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

The product attempts to initialize a resource but does not correctly do so, which might leave the resource in an unexpected, incorrect, or insecure state when it is accessed.

Extended Description

This can have security implications when the associated resource is expected to have certain properties or values. Examples include a variable that determines whether a user has been authenticated or not, or a register or fuse value that determines the security state of the product.

For software, this weakness can frequently occur when implicit initialization is used, meaning the resource is not explicitly set to a specific value. For example, in C, memory is not necessarily cleared when it is allocated on the stack, and many scripting languages use a default empty, null value, or zero value when a variable is not explicitly initialized.

For hardware, this weakness frequently appears with reset values and fuses. After a product reset, hardware may initialize registers incorrectly. During different phases of a product lifecycle, fuses may be set to incorrect values. Even if fuses are set to correct values, the lines to the fuse could be broken or there might be hardware on the fuse line that alters the fuse value to be incorrect.

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Impact	Details
Read Memory; Read Application Data; Unexpected State	Scope: Confidentiality Likelihood: Unknown
Gain Privileges or Assume Identity	Scope: Authorization, Integrity
Varies by Context	Scope: Other The technical impact can vary widely based on how the resource is used in the product, and whether its contents affect security decisions.

Potential Mitigations

Phase(s)	Mitigation
Implementation	Choose the safest-possible initialization for security-related resources.
Implementation	Ensure that each resource (whether variable, memory buffer, register, etc.) is fully initialized.
Implementation	Pay close attention to complex conditionals or reset sources that affect initialization, since some paths might not perform the initialization.
Architecture and Design	Ensure that the design and architecture clearly identify what the initialization should be, and that the initialization does not have security implications.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	665	Improper Initialization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	454	External Initialization of Trusted Variables or Data Stores
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1051	Initialization with Hard-Coded Network Resource Configuration Data
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1052	Excessive Use of Hard-Coded Literals in Initialization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1188	Initialization of a Resource with an Insecure Default
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1221	Incorrect Register Defaults or Module Parameters

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation
Manufacturing
Installation
System Configuration
Operation

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages	Class: Not Language-Specific (Undetermined Prevalence)
Operating Systems	Class: Not OS-Specific (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: Not Technology-Specific (Undetermined Prevalence)

Demonstrative Examples

Example 1

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.

(bad code)

Example Language: Verilog

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

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

In the example design, both registers will be software writable since Secure_mode is defined as zero.

(good code)

Example Language: 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)

);

Example 2

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

(bad code)

Example Language: PHP

// $user and $pass automatically set from POST request
if (login_user($user,$pass)) {

$authorized = true;

}
...

if ($authorized) {

generatePage();

}

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.

Here is a fixed version:

(good code)

Example Language: PHP

$user = $_POST['user'];
$pass = $_POST['pass'];
$authorized = false;
if (login_user($user,$pass)) {

$authorized = true;

}
...

This code avoids the issue by initializing the $authorized variable to false and explicitly retrieving the login credentials from the $_POST variable. Regardless, register_globals should never be enabled and is disabled by default in current versions of PHP.

Example 3

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.

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.

(bad code)

Example Language: Verilog

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

...

To fix this issue, the access control registers must be properly initialized during the reset phase of the SoC. Correct initialization values should be established to maintain the system's integrity, security, predictable behavior, and allow proper control of peripherals. The specifics of what values should be set depend on the SoC's design and the requirements of the system. To address the problem depicted in the bad code example [REF-1438], the default value for "acct_mem" should be set to 32'h00000000 (see good code example [REF-1439]). This ensures that during startup or after any reset, access to protected data is restricted until the system setup is complete and security procedures properly configure the access control settings.

(good code)

Example Language: Verilog

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'h00000000;

end

...

Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference	Description
CVE-2020-27211	Chain: microcontroller system-on-chip uses a register value stored in flash to set product protection state on the memory bus and does not contain protection against fault injection (CWE-1319) which leads to an incorrect initialization of the memory bus (CWE-1419) causing the product to be in an unprotected state.
CVE-2023-25815	chain: a change in an underlying package causes the gettext function to use implicit initialization with a hard-coded path (CWE-1419) under the user-writable C:\ drive, introducing an untrusted search path element (CWE-427) that enables spoofing of messages.
CVE-2022-43468	WordPress module sets internal variables based on external inputs, allowing false reporting of the number of views
CVE-2022-36349	insecure default variable initialization in BIOS firmware for a hardware board allows DoS
CVE-2015-7763	distributed filesystem only initializes part of the variable-length padding for a packet, allowing attackers to read sensitive information from previously-sent packets in the same memory location

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management

Vulnerability Mapping Notes

Usage	ALLOWED-WITH-REVIEW (this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason	Abstraction
Rationale	This CWE entry is a Class and might have Base-level children that would be more appropriate
Comments	Examine children of this entry to see if there is a better fit

References

[REF-1437]	"acct_wrapper.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/65d0ffdab7426da4509c98d62e163bcce642f651/piton/design/chip/tile/ariane/src/acct/acct_wrapper.sv#L39>.
[REF-1438]	"Bad Code acct_wrapper.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/65d0ffdab7426da4509c98d62e163bcce642f651/piton/design/chip/tile/ariane/src/acct/acct_wrapper.sv#L79C1-L86C16>.
[REF-1439]	"Good Code acct_wrapper.sv". 2021. <https://github.com/HACK-EVENT/hackatdac21/blob/062de4f25002d2dcbdb0a82af36b80a517592612/piton/design/chip/tile/ariane/src/acct/acct_wrapper.sv#L84>.

Content History

Submissions
Submission Date	Submitter	Organization
2023-10-11 (CWE 4.13, 2023-10-26)	CWE Content Team	MITRE
2023-10-11 (CWE 4.13, 2023-10-26)
Contributions
Contribution Date	Contributor	Organization
2023-10-13	Anonymous External Contributor
2023-10-13	Provided HW specific comments for Extended Description
2023-10-13	Mohan Lal	NVIDIA
2023-10-13	Provided HW specific comments for Extended Description
2023-11-07	Chen Chen, Rahul Kande, Jeyavijayan Rajendran	Texas A&M University
2023-11-07	suggested demonstrative example
2023-11-07	Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi	Technical University of Darmstadt
2023-11-07	suggested demonstrative example
Modifications
Modification Date	Modifier	Organization
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Demonstrative_Examples, References


	Site Map \| Terms of Use \| Manage Cookies \| Cookie Notice \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-1419: Incorrect Initialization of Resource

Edit Custom Filter