Skip to content
  1. Mar 05, 2018
  2. Mar 04, 2018
  3. Mar 03, 2018
  4. Mar 02, 2018
  5. Mar 01, 2018
  6. Feb 26, 2018
    • Dr. Matthias St. Pierre's avatar
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · b3f9b401
      Dr. Matthias St. Pierre authored
      Fixes #5405, #1381
      
      The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes.
      When processing input in PEM format it can happen in rare cases that
      
      - the trailing PEM marker crosses the boundary of a chunk, and
      - the beginning of the following chunk contains valid base64 encoded data.
      
      This happened in issue #5405, where the PEM marker was split into
      "-----END CER" and "TIFICATE-----" at the end of the first chunk.
      
      The decoding of the first chunk terminated correctly at the '-' character,
      which is treated as an EOF marker, and b64_read() returned. However,
      when called the second time, b64_read() read the next chunk and interpreted
      the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes
      '4c 81 48 08 04 c4'.
      
      This patch restores the assignment of the error code to 'ctx->cont', which
      was deleted accidentally in commit 5562cfac
      
       and which prevents b64_read()
      from reading additional data on subsequent calls.
      
      This issue was observed and reported by Annie Yousar.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5422)
      b3f9b401
  7. Feb 22, 2018
  8. Feb 21, 2018
  9. Feb 13, 2018
  10. Feb 09, 2018
  11. Feb 02, 2018
  12. Feb 01, 2018
    • David Benjamin's avatar
      Don't leak the exponent bit width in BN_mod_exp_mont_consttime. · 4981e6fc
      David Benjamin authored
      
      
      The exponent here is one of d, dmp1, or dmq1 for RSA. This value and its
      bit length are both secret. The only public upper bound is the bit width
      of the corresponding modulus (RSA n, p, and q, respectively).
      
      Although BN_num_bits is constant-time (sort of; see bn_correct_top notes
      in preceding patch), this does not fix the root problem, which is that
      the windows are based on the minimal bit width, not the upper bound. We
      could use BN_num_bits(m), but BN_mod_exp_mont_consttime is public API
      and may be called with larger exponents. Instead, use all top*BN_BITS2
      bits in the BIGNUM. This is still sensitive to the long-standing
      bn_correct_top leak, but we need to fix that regardless.
      
      This may cause us to do a handful of extra multiplications for RSA keys
      which are just above a whole number of words, but that is not a standard
      RSA key size.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5154)
      
      (cherry picked from commit 39eeb64f)
      4981e6fc
    • David Benjamin's avatar
      Make BN_num_bits_word constant-time. · 66509ddb
      David Benjamin authored
      
      
      (This patch was written by Andy Polyakov. I only wrote the commit
      message. Mistakes in the analysis are my fault.)
      
      BN_num_bits, by way of BN_num_bits_word, currently leaks the
      most-significant word of its argument via branching and memory access
      pattern.
      
      BN_num_bits is called on RSA prime factors in various places. These have
      public bit lengths, but all bits beyond the high bit are secret. This
      fully resolves those cases.
      
      There are a few places where BN_num_bits is called on an input where the
      bit length is also secret. This does *not* fully resolve those cases as
      we still only look at the top word. Today, that is guaranteed to be
      non-zero, but only because of the long-standing bn_correct_top timing
      leak. Once that is fixed, a constant-time BN_num_bits on such inputs
      must count bits on each word.
      
      Instead, those cases should not call BN_num_bits at all. In particular,
      BN_mod_exp_mont_consttime uses the exponent bit width to pick windows,
      but it should be using the maximum bit width. The next patch will fix
      this.
      
      Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu
      for reporting this issue.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5154)
      
      (cherry picked from commit 972c87df)
      66509ddb
  13. Jan 30, 2018
    • Matt Caswell's avatar
      Make sure we check an incoming reneg ClientHello in DTLS · d498e526
      Matt Caswell authored
      
      
      In TLS we have a check to make sure an incoming reneg ClientHello is
      acceptable. The equivalent check is missing in the DTLS code. This means
      that if a client does not signal the ability to handle secure reneg in the
      initial handshake, then a subsequent reneg handshake should be rejected by
      the server. In the DTLS case the reneg was being allowed if the the 2nd
      ClientHello had a renegotiation_info extension. This is incorrect.
      
      While incorrect, this does not represent a security issue because if
      the renegotiation_info extension is present in the second ClientHello it
      also has to be *correct*. Therefore this will only work if both the client
      and server believe they are renegotiating, and both know the previous
      Finished result. This is not the case in an insecure rengotiation attack.
      
      I have also tidied up the check in the TLS code and given a better check
      for determining whether we are renegotiating or not.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5192)
      d498e526
  14. Jan 24, 2018
  15. Jan 23, 2018
  16. Jan 22, 2018
  17. Jan 21, 2018
  18. Jan 16, 2018
    • Matt Caswell's avatar
      Revert BN_copy() flag copy semantics change · 8837a048
      Matt Caswell authored
      Commit 9f944291
      
       changed the semantics of BN_copy() to additionally
      copy the BN_FLG_CONSTTIME flag if it is set. This turns out to be
      ill advised as it has unintended consequences. For example calling
      BN_mod_inverse_no_branch() can sometimes return a result with the flag
      set and sometimes not as a result. This can lead to later failures if we
      go down code branches that do not support constant time, but check for
      the presence of the flag.
      
      The original commit was made due to an issue in BN_MOD_CTX_set(). The
      original PR fixed the problem in that function, but it was changed in
      review to fix it in BN_copy() instead. The solution seems to be to revert
      the BN_copy() change and go back to the originally proposed way.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/5080)
      
      (cherry picked from commit 7d461736)
      8837a048
  19. Jan 09, 2018
    • Matt Caswell's avatar
      Tolerate DTLS alerts with an incorrect version number · da9ed725
      Matt Caswell authored
      
      
      In the case of a protocol version alert being sent by a peer the record
      version number may not be what we are expecting. In DTLS records with an
      unexpected version number are silently discarded. This probably isn't
      appropriate for alerts, so we tolerate a mismatch in the minor version
      number.
      
      This resolves an issue reported on openssl-users where an OpenSSL server
      chose DTLS1.0 but the client was DTLS1.2 only and sent a protocol_version
      alert with a 1.2 record number. This was silently ignored by the server.
      
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5019)
      da9ed725
  20. Jan 07, 2018
  21. Jan 06, 2018
  22. Jan 05, 2018
  23. Dec 27, 2017
  24. Dec 23, 2017
  25. Dec 13, 2017
  26. Dec 11, 2017
  27. Dec 10, 2017
  28. Dec 09, 2017
  29. Dec 08, 2017