urandom shm attack?

[D. J. Bernstein]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230114/f1c5a3b7/attachment.sig>