Skip to content
  1. Mar 18, 2019
  2. Mar 07, 2019
    • Bernd Edlinger's avatar
      Fix memory overrun in rsa padding check functions · 7ebbb293
      Bernd Edlinger authored
      
      
      Fixes #8364 and #8357
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/8365)
      
      (cherry picked from commit d7f5e5ae)
      7ebbb293
    • Matt Caswell's avatar
      Avoid an underflow in ecp_nistp521.c · a8e129a0
      Matt Caswell authored
      
      
      The function felem_diff_128_64 in ecp_nistp521.c substracts the number |in|
      from |out| mod p. In order to avoid underflow it first adds 32p mod p
      (which is equivalent to 0 mod p) to |out|. The comments and variable naming
      suggest that the original author intended to add 64p mod p. In fact it
      has been shown that with certain unusual co-ordinates it is possible to
      cause an underflow in this function when only adding 32p mod p while
      performing a point double operation. By changing this to 64p mod p the
      underflow is avoided.
      
      It turns out to be quite difficult to construct points that satisfy the
      underflow criteria although this has been done and the underflow
      demonstrated. However none of these points are actually on the curve.
      Finding points that satisfy the underflow criteria and are also *on* the
      curve is considered significantly more difficult. For this reason we do
      not believe that this issue is currently practically exploitable and
      therefore no CVE has been assigned.
      
      This only impacts builds using the enable-ec_nistp_64_gcc_128 Configure
      option.
      
      With thanks to Bo-Yin Yang, Billy Brumley and Dr Liu for their significant
      help in investigating this issue.
      
      Reviewed-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8405)
      
      (cherry picked from commit 13fbce17)
      a8e129a0
  3. Mar 06, 2019
    • Matt Caswell's avatar
      Test an overlong ChaCha20-Poly1305 nonce · 09af525c
      Matt Caswell authored
      
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8406)
      
      (cherry picked from commit a4f0b50e)
      09af525c
    • Matt Caswell's avatar
      Prevent over long nonces in ChaCha20-Poly1305 · ee22257b
      Matt Caswell authored
      
      
      ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for
      every encryption operation. RFC 7539 specifies that the nonce value (IV)
      should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and
      front pads the nonce with 0 bytes if it is less than 12 bytes. However it
      also incorrectly allows a nonce to be set of up to 16 bytes. In this case
      only the last 12 bytes are significant and any additional leading bytes are
      ignored.
      
      It is a requirement of using this cipher that nonce values are unique.
      Messages encrypted using a reused nonce value are susceptible to serious
      confidentiality and integrity attacks. If an application changes the
      default nonce length to be longer than 12 bytes and then makes a change to
      the leading bytes of the nonce expecting the new value to be a new unique
      nonce then such an application could inadvertently encrypt messages with a
      reused nonce.
      
      Additionally the ignored bytes in a long nonce are not covered by the
      integrity guarantee of this cipher. Any application that relies on the
      integrity of these ignored leading bytes of a long nonce may be further
      affected.
      
      Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe
      because no such use sets such a long nonce value. However user
      applications that use this cipher directly and set a non-default nonce
      length to be longer than 12 bytes may be vulnerable.
      
      CVE-2019-1543
      
      Fixes #8345
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8406)
      
      (cherry picked from commit 2a3d0ee9)
      ee22257b
  4. Feb 26, 2019
  5. Feb 25, 2019
    • Matt Caswell's avatar
      Ensure bn_cmp_words can handle the case where n == 0 · ad01b01c
      Matt Caswell authored
      
      
      Thanks to David Benjamin who reported this, performed the analysis and
      suggested the patch. I have incorporated some of his analysis in the
      comments below.
      
      This issue can cause an out-of-bounds read. It is believed that this was
      not reachable until the recent "fixed top" changes. Analysis has so far
      only identified one code path that can encounter this - although it is
      possible that others may be found. The one code path only impacts 1.0.2 in
      certain builds. The fuzzer found a path in RSA where iqmp is too large. If
      the input is all zeros, the RSA CRT logic will multiply a padded zero by
      iqmp. Two mitigating factors:
      
      - Private keys which trip this are invalid (iqmp is not reduced mod p).
      Only systems which take untrusted private keys care.
      - In OpenSSL 1.1.x, there is a check which rejects the oversize iqmp,
      so the bug is only reproducible in 1.0.2 so far.
      
      Fortunately, the bug appears to be relatively harmless. The consequences of
      bn_cmp_word's misbehavior are:
      
      - OpenSSL may crash if the buffers are page-aligned and the previous page is
      non-existent.
      - OpenSSL will incorrectly treat two BN_ULONG buffers as not equal when they
      are equal.
      - Side channel concerns.
      
      The first is indeed a concern and is a DoS bug. The second is fine in this
      context. bn_cmp_word and bn_cmp_part_words are used to compute abs(a0 - a1)
      in Karatsuba. If a0 = a1, it does not matter whether we use a0 - a1 or
      a1 - a0. The third would be worth thinking about, but it is overshadowed
      by the entire Karatsuba implementation not being constant time.
      
      Due to the difficulty of tripping this and the low impact no CVE is felt
      necessary for this issue.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8326)
      
      (cherry picked from commit 576129cd)
      ad01b01c
  6. Feb 24, 2019
  7. Feb 21, 2019
    • Nicola Tuveri's avatar
      Clear BN_FLG_CONSTTIME on BN_CTX_get() · f499873c
      Nicola Tuveri authored
      (cherry picked from commit c8147d37
      
      )
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8294)
      f499873c
    • Nicola Tuveri's avatar
      Test for constant-time flag leakage in BN_CTX · c4e901db
      Nicola Tuveri authored
      This commit adds a simple unit test to make sure that the constant-time
      flag does not "leak" among BN_CTX frames:
      
      - test_ctx_consttime_flag() initializes (and later frees before
        returning) a BN_CTX object, then it calls in sequence
        test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same
        BN_CTX object. The process is run twice, once with a "normal"
        BN_CTX_new() object, then with a BN_CTX_secure_new() one.
      - test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the
        BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame
        before ending it.
      - test_ctx_check_ct_flag() then starts a new frame and gets a number of
        BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new
        frame should have BN_FLG_CONSTTIME set.
      
      In actual BN_CTX usage inside libcrypto the leak could happen at any
      depth level in the BN_CTX stack, with varying results depending on the
      patterns of sibling trees of nested function calls sharing the same
      BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the
      called BN_* functions.
      
      This simple unit test abstracts away this complexity and verifies that
      the leak does not happen between two sibling functions sharing the same
      BN_CTX object at the same level of nesting.
      
      (manually cherry picked from commit fe16ae5f
      
      )
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8294)
      c4e901db
  8. Feb 20, 2019
  9. Feb 18, 2019
  10. Feb 11, 2019
  11. Jan 31, 2019
  12. Dec 12, 2018
  13. Dec 08, 2018
  14. Dec 07, 2018
  15. Nov 24, 2018
  16. Nov 23, 2018
  17. Nov 20, 2018
  18. Nov 13, 2018