urandom shm attack?

[rsbecker at nexbridge.com]

On January 15, 2023 2:43 PM D. J. Bernstein wrote:
>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

I think the disable should be applicable to other systems, as with
50-nonstop, which does not have a secure /dev/*random. The latest x86 uses
hardware randomization while older ones use PRNGD. So instead of doing this
for just __linux, please allow the blanket disable to be configurable,
although 50-nonstop derives from the unix template.

--Randall