There are well-known security risks for applications using /dev/urandom on pre-getrandom Linux systems. OpenSSL addressed this in 1.1.1d (after preliminary work in 1.1.1c) as follows: Early start up entropy quality from the DEVRANDOM seed source has been improved for older Linux systems. The RAND subsystem will wait for /dev/random to be producing output before seeding from /dev/urandom. The seeded state is stored for future library initialisations using a system global shared memory segment. But what happens if an attacker has the ability to run code on the same machine, under whichever unprivileged account? I've looked briefly at rand_unix.c and don't see any protection against the attacker creating shared-memory segment 114. It then doesn't seem true that the RAND subsystem "will wait for /dev/random to be producing output": OpenSSL under other accounts will use guessable /dev/urandom output, for example to create long-term keys. Am I missing something? Of course, one can always _hope_ that attackers can't run code locally, especially in the early boot stages where /dev/urandom on these systems is maximally vulnerable. But I'd think that it's safer to have OpenSSL poll /dev/random if, say, /run/urandom-ready doesn't exist, and to recommend adding something like dd count=1 bs=64 if=/dev/random of=/dev/urandom status=none \ && findmnt -t tmpfs -T /run >/dev/null && touch /run/urandom-ready to the boot scripts for Linux systems. ---D. J. Bernstein
Attachment:
signature.asc
Description: PGP signature
