urandom shm attack?

[Tomas Mraz]

On any recent (even not so recent) Linux kernels which have getrandom
syscall, it will be used, and the SHM workaround/hack won't be
applicable. IMO that SHM workaround was never meant to be perfect and I
do not see a reason to further complicate it when it does not apply to
contemporary Linux distributions anyway.

Tomas Mraz, OpenSSL

On Sat, 2023-01-14 at 16:31 -0800, Ethan Rahn wrote:
> 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 at box.cr.yp.to> 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

-- 
Tomáš Mráz, OpenSSL