Re: lib/56905: getentropy() may return predictable data

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR lib/56905; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/56905: getentropy() may return predictable data
Date: Fri, 22 Jul 2022 14:22:12 +0300

 The situation is even more complicated that I thought.
 
 I thought adding getentropy() as a new libc function would only affect
 third-party software because nothing in the base system would be using
 a function that did not yet exist, but it turns out I was wrong.  The
 OpenSSL library in base actually detects the presence of getentropy()
 at run time, and now ends up calling getentropy() rather than
 sysctl(KERN_ARND).
 
 Therefore, changing getentropy() to have the proper blocking semantics
 would have the side effect of causing many programs in the NetBSD base
 system that rely on OpenSSL, such as ssh-keygen(1), syslogd(8), and
 login(1), to also block until entropy is available.  That would be a
 good thing from a security perspective, and might have worked in -9
 where processes blocking for entropy eventually get unblocked, but
 regrettably, in -current they no longer do on some systems.  Since
 login(1) blocking forever would render the system unusable and not
 easily recoverable, making OpenSSL block is not a realistic option
 until the root cause of the blocking problems in -current, the
 persistent lack of entropy (or lack of belief in the entropy that is
 present), is fixed.
 
 If the intent when adding getentropy() to libc really was just to
 introduce the symbol into libc for reasons of ABI compatibility, and
 not to switch OpenSSL over to it, perhaps OpenSSL could be patched to
 ignore it, as in the patch below.  But this would just be a stopgap
 measure that effectively amounts to perpetuating a long-standing
 vulnerability in OpenSSL so that a new one in getentropy() can be
 fixed.
 
 Index: src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c
 ===================================================================
 RCS file: /cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c,v
 retrieving revision 1.18
 diff -u -r1.18 rand_unix.c
 --- src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c	7 Jan 2022 15:50:11 -0000	1.18
 +++ src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c	21 Jul 2022 12:16:43 -0000
 @@ -370,7 +370,9 @@
       * Note: Sometimes getentropy() can be provided but not implemented
       * internally. So we need to check errno for ENOSYS
       */
 -#  if defined(__GNUC__) && __GNUC__>=2 && defined(__ELF__) && !defined(__hpux)
 +#  if defined(__NetBSD__)
 +    /* Avoid getentropy() while its semantics are still being debated */
 +#  elif defined(__GNUC__) && __GNUC__>=2 && defined(__ELF__) && !defined(__hpux)
      extern int getentropy(void *buffer, size_t length) __attribute__((weak));
  
      if (getentropy != NULL) {
 
 -- 
 Andreas Gustafsson, gson%gson.org@localhost