Predictable Seed in Pseudo-Random Number Generator (PRNG)

Draft Variant
Structure: Simple
Description

A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.

Extended Description

The use of predictable seeds significantly reduces the number of possible seeds that an attacker would need to test in order to predict which random numbers will be generated by the PRNG.

Common Consequences 1
Scope: Other

Impact: Varies by Context

Potential Mitigations 3
Use non-predictable inputs for seed generation.
Phase: Architecture and DesignRequirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible.
Phase: Implementation
Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
Demonstrative Examples 1

ID : DX-102

Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:

Code Example:

Bad
Java
java

Code Example:

Bad
C
c
An attacker can easily predict the seed used by these PRNGs, and so also predict the stream of random numbers generated. Note these examples also exhibit Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) (Use of Cryptographically Weak PRNG).
Observed Examples 5
CVE-2020-7010Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
CVE-2019-11495server uses erlang:now() to seed the PRNG, which results in a small search space for potential random seeds
CVE-2008-0166The removal of a couple lines of code caused Debian's OpenSSL Package to only use the current process ID for seeding a PRNG
CVE-2016-10180Router's PIN generation is based on rand(time(0)) seeding.
CVE-2018-9057cloud provider product uses a non-cryptographically secure PRNG and seeds it with the current time
References 3
FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology
25-05-2001
ID: REF-267
FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology
22-03-2019
ID: REF-1192
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • PLOVER
  • The CERT Oracle Secure Coding Standard for Java (2011)
Notes
MaintenanceAs of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.