Dr. Bernstein,
A couple questions:
- Aren't you relying on filesystem permissions for /run/urandom-ready to correctly prevent local attackers from adding that file?
- I'm under the impression that boot scripts for Linux systems are the responsibility of the distro maintainers to package. Wouldn't they be the better audience for this request, as well as able to assess if /run/ would have it's filesystem permissions set properly?
Cheers,
Ethan
On Sat, Jan 14, 2023 at 10:21 AM D. J. Bernstein <posting-openssl-users@xxxxxxxxxxxx> wrote:
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
