Non-exit on Failed Initialization

Draft Base
Structure: Simple
Description

The product does not exit or otherwise modify its operation when security-relevant errors occur during initialization, such as when a configuration file has a format error or a hardware security module (HSM) cannot be activated, which can cause the product to execute in a less secure fashion than intended by the administrator.

Common Consequences 1
Scope: IntegrityOther

Impact: Modify Application DataAlter Execution Logic

The application could be placed in an insecure state that may allow an attacker to modify sensitive data or allow unintended logic to be executed.

Potential Mitigations 1
Phase: Implementation
Follow the principle of failing securely when an error occurs. The system should enter a state where it is not vulnerable and will not display sensitive error messages to a potential attacker.
Demonstrative Examples 1

ID : DX-54

The following code intends to limit certain operations to the administrator only.

Code Example:

Bad
Perl
perl

do stuff*

perl
If the application is unable to extract the state information - say, due to a database timeout - then the $uid variable will not be explicitly set by the programmer. This will cause $uid to be regarded as equivalent to "0" in the conditional, allowing the original user to perform administrator actions. Even if the attacker cannot directly influence the state data, unexpected errors could cause incorrect privileges to be assigned to a user just by accident.
Observed Examples 1
CVE-2005-1345Product does not trigger a fatal error if missing or invalid ACLs are in a configuration file.
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • PLOVER
Notes
Research GapUnder-studied. These issues are not frequently reported, and it is difficult to find published examples.