<div dir="ltr">Dr. Bernstein,<div><br></div><div>A couple questions:</div><div><br></div><div>- Aren't you relying on filesystem permissions for /run/urandom-ready to correctly prevent local attackers from adding that file?</div><div>- 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?</div><div><br></div><div>Cheers,</div><div><br></div><div>Ethan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023 at 10:21 AM D. J. Bernstein <<a href="mailto:posting-openssl-users@box.cr.yp.to">posting-openssl-users@box.cr.yp.to</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There are well-known security risks for applications using /dev/urandom<br>
on pre-getrandom Linux systems. OpenSSL addressed this in 1.1.1d (after<br>
preliminary work in 1.1.1c) as follows:<br>
<br>
   Early start up entropy quality from the DEVRANDOM seed source has<br>
   been improved for older Linux systems.  The RAND subsystem will wait<br>
   for /dev/random to be producing output before seeding from<br>
   /dev/urandom.  The seeded state is stored for future library<br>
   initialisations using a system global shared memory segment.<br>
<br>
But what happens if an attacker has the ability to run code on the same<br>
machine, under whichever unprivileged account?<br>
<br>
I've looked briefly at rand_unix.c and don't see any protection against<br>
the attacker creating shared-memory segment 114. It then doesn't seem<br>
true that the RAND subsystem "will wait for /dev/random to be producing<br>
output": OpenSSL under other accounts will use guessable /dev/urandom<br>
output, for example to create long-term keys. Am I missing something?<br>
<br>
Of course, one can always _hope_ that attackers can't run code locally,<br>
especially in the early boot stages where /dev/urandom on these systems<br>
is maximally vulnerable. But I'd think that it's safer to have OpenSSL<br>
poll /dev/random if, say, /run/urandom-ready doesn't exist, and to<br>
recommend adding something like<br>
<br>
   dd count=1 bs=64 if=/dev/random of=/dev/urandom status=none \<br>
   && findmnt -t tmpfs -T /run >/dev/null && touch /run/urandom-ready<br>
<br>
to the boot scripts for Linux systems.<br>
<br>
---D. J. Bernstein<br>
</blockquote></div>