urandom shm attack?

[D. J. Bernstein]

Ethan Rahn writes:
> - Aren't you relying on filesystem permissions for /run/urandom-ready to
> correctly prevent local attackers from adding that file?

Yes, exactly. FHS says "/run should not be writable for unprivileged
users; it is a major security problem if any user can write in this
directory."

There are non-FHS systems, but I've checked a bunch of machines and so
far haven't found any where /run---or, to be more portable, /var/run---
is writable by non-root.

Even if there are some systems where a regular user can create
/var/run/urandom-ready, the resulting attack would be exactly what
OpenSSL allows currently. Meanwhile this change would close the attack
on other systems, while simplifying the OpenSSL code.

> - 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?

No, these boot-script changes would generally be made by sysadmins
running pre-getrandom machines rather than by OS distributions.

Meanwhile the security issue comes from OpenSSL code that's documented
by OpenSSL as waiting for /dev/random before using /dev/urandom, but
that doesn't achieve this property if an account on the same machine
happens to be running attack code.

Tomas Mraz writes:
> 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.

That's my impression, yes, although the mechanism selecting getrandom()
isn't particularly easy to audit.

Meanwhile there are still many pre-getrandom Linux systems, such as
gcc22 (MIPS, kernel 3.14) in the GCC Compile Farm. My experience is that
embedded systems are split between

   * user-space updates and kernel updates working,
   * user-space updates working but kernel updates not working, and
   * "updates? what are those?";

changes in how OpenSSL treats pre-getrandom kernels will apply to many
systems in the second category.

> 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.

Hmmm. Is OpenSSL dropping support for pre-getrandom Linux systems? If
so, then I'd suggest

   * documenting this,

   * blanket disabling the /dev/*random code if __linux is defined, and

   * removing the breakable-by-a-local-attacker shm calls.

If, on the other hand, OpenSSL is continuing to support pre-getrandom
Linux systems for the moment, then I'd suggest

   * replacing OpenSSL's shm calls with a check for the existence of
     /var/run/urandom-ready (this addresses the attack at hand), and

   * adding the boot-script suggestion to the OpenSSL documentation
     (this deals with the most likely performance issues).

Either way, the code will end up simpler and more robust.

---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/20230115/ddfbd712/attachment.sig>