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
Attachment:
signature.asc
Description: PGP signature
