Skip to content
  1. Aug 20, 2019
    • Pauli's avatar
      Start up DEVRANDOM entropy improvement for older Linux devices. · 3ff98f55
      Pauli authored
      
      
      Improve handling of low entropy at start up from /dev/urandom by waiting for
      a read(2) call on /dev/random to succeed.  Once one such call has succeeded,
      a shared memory segment is created and persisted as an indicator to other
      processes that /dev/urandom is properly seeded.
      
      This does not fully prevent against attacks weakening the entropy source.
      An attacker who has control of the machine early in its boot sequence
      could create the shared memory segment preventing detection of low entropy
      conditions.  However, this is no worse than the current situation.
      
      An attacker would also be capable of removing the shared memory segment
      and causing seeding to reoccur resulting in a denial of service attack.
      This is partially mitigated by keeping the shared memory alive for the
      duration of the process's existence.  Thus, an attacker would not only need
      to have called call shmctl(2) with the IPC_RMID command but the system
      must subsequently enter a state where no instances of libcrypto exist in
      any process.  Even one long running process will prevent this attack.
      
      The System V shared memory calls used here go back at least as far as
      Linux kernel 2.0.  Linux kernels 4.8 and later, don't have a reliable way
      to detect that /dev/urandom has been properly seeded, so a failure is raised
      for this case (i.e. the getentropy(2) call has already failed).
      
      Reviewed-by: default avatarBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/9595)
      
      [manual merge]
      3ff98f55
  2. Aug 19, 2019
  3. Aug 18, 2019
  4. Aug 17, 2019
  5. Aug 15, 2019
  6. Aug 14, 2019
  7. Aug 13, 2019
  8. Aug 12, 2019
  9. Aug 09, 2019
  10. Aug 08, 2019
  11. Aug 06, 2019
  12. Aug 05, 2019
    • Matt Caswell's avatar
      Fix SSL_MODE_RELEASE_BUFFERS functionality · f2bb79a7
      Matt Caswell authored
      
      
      At some point in the past do_ssl3_write() used to return the number of
      bytes written, or a value <= 0 on error. It now just returns a success/
      error code and writes the number of bytes written to |tmpwrit|.
      
      The SSL_MODE_RELEASE_BUFFERS code was still looking at the return code
      for the number of bytes written rather than |tmpwrit|. This has the effect
      that the buffers are not released when they are supposed to be.
      
      Fixes #9490
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/9505)
      
      (cherry picked from commit 8bbf63e48f27c5edaa03e6d87d969c9b6a207f3c)
      f2bb79a7
  13. Aug 01, 2019
  14. Jul 31, 2019
  15. Jul 30, 2019
    • Bernd Edlinger's avatar
      Use OPENSSL_strlcpy instead of strncpy in e_afalg.c · 74f4cc02
      Bernd Edlinger authored
      
      
      This avoids a spurious gcc warning:
      ./config enable-asan --strict-warnings
      =>
      In function 'afalg_create_sk',
          inlined from 'afalg_cipher_init' at engines/e_afalg.c:545:11:
      engines/e_afalg.c:376:5: error: '__builtin_strncpy' output may be
          truncated copying 63 bytes from a string of length 63 [-Werror=stringop-truncation]
        376 |     strncpy((char *) sa.salg_name, ciphername, ALG_MAX_SALG_NAME);
            |     ^~~~~~~
      
      [extended tests]
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/9478)
      
      (cherry picked from commit 62cc845fc955c8d4de7b703f57bfd8e5854f00f4)
      74f4cc02
  16. Jul 28, 2019
  17. Jul 25, 2019