Skip to content
  1. Mar 07, 2019
    • Matt Caswell's avatar
      Add a test for underflow in ecp_nistp521.c · acd9b16b
      Matt Caswell authored
      
      
      The previous commit fixed an underflow that may occur in ecp_nistp521.c.
      This commit adds a test for that condition. It is heavily based on an
      original test harness by Billy Brumley.
      
      Reviewed-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8405)
      
      (cherry picked from commit 6855b496b205c067ecb276221c31c6212f4fdbae)
      acd9b16b
    • Matt Caswell's avatar
      Avoid an underflow in ecp_nistp521.c · d49b8889
      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 13fbce17fc9f02e2401fc3868f3f8e02d6647e5f)
      d49b8889
  2. Mar 06, 2019
    • Matt Caswell's avatar
      Update ChaCha20-Poly1305 documentation · f7a6d112
      Matt Caswell authored
      
      
      Correctly describe the maximum IV length.
      
      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 27d5631236325c3fd8a3bd06af282ac496aac64b)
      f7a6d112
    • Matt Caswell's avatar
      Test an overlong ChaCha20-Poly1305 nonce · 9b10d1bf
      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 a4f0b50eafb256bb802f2724fc7f7580fb0fbabc)
      9b10d1bf
    • Matt Caswell's avatar
      Prevent over long nonces in ChaCha20-Poly1305 · f426625b
      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 2a3d0ee9d59156c48973592331404471aca886d6)
      f426625b
  3. Mar 05, 2019
  4. Mar 04, 2019
  5. Mar 01, 2019
  6. Feb 28, 2019
  7. Feb 27, 2019
  8. Feb 26, 2019
  9. Feb 25, 2019
    • Richard Levitte's avatar
      Rearrange the inclusion of curve448/curve448_lcl.h · f408e2a3
      Richard Levitte authored
      
      
      The real cause for this change is that test/ec_internal_test.c
      includes ec_lcl.h, and including curve448/curve448_lcl.h from there
      doesn't work so well with compilers who always do inclusions relative
      to the C file being compiled.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8334)
      f408e2a3
    • Matt Caswell's avatar
      Ensure bn_cmp_words can handle the case where n == 0 · df2cb82a
      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 576129cd72ae054d246221f111aabf42b9c6d76d)
      df2cb82a
  10. Feb 22, 2019
    • Richard Levitte's avatar
      Windows: Call TerminateProcess, not ExitProcess · 4af54c9b
      Richard Levitte authored
      Ty Baen-Price explains:
      
      > Problem and Resolution:
      > The following lines of code make use of the Microsoft API ExitProcess:
      >
      > ```
      > Apps\Speed.c line 335:	ExitProcess(ret);
      > Ms\uplink.c line 22: ExitProcess(1);
      > ```
      >
      > These function calls are made after fatal errors are detected and
      > program termination is desired. ExitProcess(), however causes
      > _orderly_ shutdown of a process and all its threads, i.e. it unloads
      > all dlls and runs all destructors. See MSDN for details of exactly
      > what happens
      > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
      
      ).
      > The MSDN page states that ExitProcess should never be called unless
      > it is _known to be safe_ to call it. These calls should simply be
      > replaced with calls to TerminateProcess(), which is what should be
      > called for _disorderly_ shutdown.
      >
      > An example of usage:
      >
      > ```
      > TerminateProcess(GetCurrentProcess(), exitcode);
      > ```
      >
      > Effect of Problem:
      > Because of a compilation error (wrong c++ runtime), my program
      > executed the uplink.c ExitProcess() call. This caused the single
      > OpenSSL thread to start executing the destructors of all my dlls,
      > and their objects. Unfortunately, about 30 other threads were
      > happily using those objects at that time, eventually causing a
      > 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the
      > best case scenario, as I'm sure you can imagine at the consequences
      > of undiscovered memory corruption, even in a terminating process.
      
      And on the subject of `TerminateProcess()` being asynchronous:
      
      > That is technically true, but I think it's probably synchronous
      > "enough" for your purposes, since a call to TerminateProcess
      > suspends execution of all threads in the target process. This means
      > it's really only asynchronous if you're calling TerminateProcess one
      > some _other_ process. If you're calling TerminateProcess on your own
      > process, you'll never return from the TerminateProcess call.
      
      Fixes #2489
      Was originally RT-4526
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8301)
      
      (cherry picked from commit 92579599)
      4af54c9b
    • Matt Caswell's avatar
      Don't restrict the number of KeyUpdate messages we can process · f6d64b51
      Matt Caswell authored
      
      
      Prior to this commit we were keeping a count of how many KeyUpdates we
      have processed and failing if we had had too many. This simplistic approach
      is not sufficient for long running connections. Since many KeyUpdates
      would not be a particular good DoS route anyway, the simplest solution is
      to simply remove the key update count.
      
      Fixes #8068
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/8299)
      
      (cherry picked from commit 3409a5ff)
      f6d64b51
    • Dr. Matthias St. Pierre's avatar
      engines/dasync: add explaining comments about AES-128-CBC-HMAC-SHA1 · 4a81b8b6
      Dr. Matthias St. Pierre authored
      
      
      Fixes #7950
      
      It was reported that there might be a null pointer dereference in the
      implementation of the dasync_aes_128_cbc_hmac_sha1() cipher, because
      EVP_aes_128_cbc_hmac_sha1() can return a null pointer if AES-NI is
      not available. It took some analysis to find out that this is not
      an issue in practice, and these comments explain the reason to comfort
      further NPD hunters.
      
      Detected by GitHub user @wurongxin1987 using the Sourcebrella Pinpoint
      static analyzer.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8305)
      
      (cherry picked from commit a4a0a1eb43cfccd128d085932a567e0482fbfe47)
      4a81b8b6
    • Paul Yang's avatar
      Fix a grammar nit in CRYPTO_get_ex_new_index.pod · d600f3d3
      Paul Yang authored
      
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8303)
      
      (cherry picked from commit 84712024da5e5485e8397afc763555355bddf960)
      d600f3d3
  11. Feb 21, 2019
  12. Feb 20, 2019