CWE-332 Details

The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.

Einführungsmodi

Architecture and Design
Implementation : REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Anwendbare Plattformen

Sprache

Class: Not Language-Specific (Undetermined)

Häufige Konsequenzen

Beobachtete Beispiele

Mögliche Gegenmaßnahmen

Phases : Architecture and Design // Requirements
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
Phases : Implementation
Consider a PRNG that re-seeds itself as needed from high-quality pseudo-random output, such as hardware devices.
Phases : Architecture and Design
When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator that always uses strong random data -- i.e., a random number generator that attempts to be strong but will fail in a weak way or will always provide some middle ground of protection through techniques like re-seeding. Generally, something that always provides a predictable amount of strength is preferable.

Erkennungsmethoden

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Hinweise zur Schwachstellen-Zuordnung

Begründung : This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Kommentar : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Hinweise

As 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.

Referenzen

REF-267

FIPS PUB 140-2: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES
Information Technology Laboratory, National Institute of Standards and Technology.
https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402.pdf

REF-18

The CLASP Application Security Process
Secure Software, Inc..
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf

REF-1374

Randstorm: You Can't Patch a House of Cards
Unciphered.
https://www.unciphered.com/disclosure-of-vulnerable-bitcoin-wallet-library-2/

Einreichung

Änderungen