CWE-333, Improper Handling of Insufficient Entropy in TRNG, concerns true random number generators. These draw on physical entropy, so they produce numbers at a limited rate and can fail or block when demand outpaces supply.
It is mainly an availability problem. The affected party is whoever depends on the service staying up.
How it happens
MITRE notes that the rate at which true random numbers can be generated is limited, so they should be used only when they are needed for security. A program that requests them in bulk, or for non security tasks such as shuffling a playlist, can drain the pool. Code that does not handle the case where numbers are unavailable can then crash or hang.
# Wasteful: spending scarce entropy on a trivial task
with open("/dev/random", "rb") as f:
pick = f.read(1)[0] % len(items)
What an attacker gains
The consequence in the record is availability: denial of service through a crash, exit or restart. A program may crash or block if it runs out of random numbers. An attacker who can trigger many requests that each need random values can cause that.
How to find it
The record lists no specific detection method. Review where entropy is requested, load test paths that consume random values, and watch for blocking reads.
How to fix it
MITRE's mitigation is that rather than failing on a lack of random numbers, it is often preferable to wait for more to be created. Beyond that:
- Request true random numbers only where security needs them.
- Seed a cryptographically secure generator from the true source and draw from that for bulk needs.
- Handle the unavailable case with a timeout and a clear error, not a crash.
Quick check
Should I use a TRNG for everything?
No. Its output is limited. Use it for security needs and use ordinary generators for the rest.
