Skip to content
  1. May 03, 2016
    • Matt Caswell's avatar
      Prepare for 1.0.2h release · 5dd94f18
      Matt Caswell authored
      
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      OpenSSL_1_0_2h
      5dd94f18
    • Matt Caswell's avatar
      make update · 76564c8e
      Matt Caswell authored
      
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      76564c8e
    • Matt Caswell's avatar
      b4d56b8e
    • Dr. Stephen Henson's avatar
      Fix ASN1_INTEGER handling. · d4b25980
      Dr. Stephen Henson authored
      
      
      Only treat an ASN1_ANY type as an integer if it has the V_ASN1_INTEGER
      tag: V_ASN1_NEG_INTEGER is an internal only value which is never used
      for on the wire encoding.
      
      Thanks to David Benjamin <davidben@google.com> for reporting this bug.
      
      This was found using libFuzzer.
      
      RT#4364 (part)CVE-2016-2108.
      
      Reviewed-by: default avatarEmilia Käsper <emilia@openssl.org>
      d4b25980
    • Kurt Roeckx's avatar
      Check that we have enough padding characters. · 68595c0c
      Kurt Roeckx authored
      
      
      Reviewed-by: default avatarEmilia Käsper <emilia@openssl.org>
      
      CVE-2016-2107
      
      MR: #2572
      68595c0c
    • Matt Caswell's avatar
      Remove some documentation for functions not in 1.0.x · 643e8e97
      Matt Caswell authored
      
      
      A few functions in the recently added EVP_EncodeInit docs don't apply to
      the 1.0.x branches.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      643e8e97
    • Matt Caswell's avatar
    • Matt Caswell's avatar
      Ensure EVP_EncodeUpdate handles an output length that is too long · 3850c2b9
      Matt Caswell authored
      
      
      With the EVP_EncodeUpdate function it is the caller's responsibility to
      determine how big the output buffer should be. The function writes the
      amount actually used to |*outl|. However this could go negative with a
      sufficiently large value for |inl|. We add a check for this error
      condition.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      3850c2b9
    • Matt Caswell's avatar
      Avoid overflow in EVP_EncodeUpdate · 172c6e1e
      Matt Caswell authored
      
      
      An overflow can occur in the EVP_EncodeUpdate function which is used for
      Base64 encoding of binary data. If an attacker is able to supply very large
      amounts of input data then a length check can overflow resulting in a heap
      corruption. Due to the very large amounts of data involved this will most
      likely result in a crash.
      
      Internally to OpenSSL the EVP_EncodeUpdate function is primarly used by the
      PEM_write_bio* family of functions. These are mainly used within the
      OpenSSL command line applications, so any application which processes
      data from an untrusted source and outputs it as a PEM file should be
      considered vulnerable to this issue.
      
      User applications that call these APIs directly with large amounts of
      untrusted data may also be vulnerable.
      
      Issue reported by Guido Vranken.
      
      CVE-2016-2105
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      172c6e1e
    • Matt Caswell's avatar
      Prevent EBCDIC overread for very long strings · 9f2ccf1d
      Matt Caswell authored
      
      
      ASN1 Strings that are over 1024 bytes can cause an overread in
      applications using the X509_NAME_oneline() function on EBCDIC systems.
      This could result in arbitrary stack data being returned in the buffer.
      
      Issue reported by Guido Vranken.
      
      CVE-2016-2176
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      9f2ccf1d
    • Matt Caswell's avatar
      Fix encrypt overflow · 3ab937bc
      Matt Caswell authored
      
      
      An overflow can occur in the EVP_EncryptUpdate function. If an attacker is
      able to supply very large amounts of input data after a previous call to
      EVP_EncryptUpdate with a partial block then a length check can overflow
      resulting in a heap corruption.
      
      Following an analysis of all OpenSSL internal usage of the
      EVP_EncryptUpdate function all usage is one of two forms.
      
      The first form is like this:
      EVP_EncryptInit()
      EVP_EncryptUpdate()
      
      i.e. where the EVP_EncryptUpdate() call is known to be the first called
      function after an EVP_EncryptInit(), and therefore that specific call
      must be safe.
      
      The second form is where the length passed to EVP_EncryptUpdate() can be
      seen from the code to be some small value and therefore there is no
      possibility of an overflow.
      
      Since all instances are one of these two forms, I believe that there can
      be no overflows in internal code due to this problem.
      
      It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate()
      in certain code paths. Also EVP_CipherUpdate() is a synonym for
      EVP_EncryptUpdate(). Therefore I have checked all instances of these
      calls too, and came to the same conclusion, i.e. there are no instances
      in internal usage where an overflow could occur.
      
      This could still represent a security issue for end user code that calls
      this function directly.
      
      CVE-2016-2106
      
      Issue reported by Guido Vranken.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      (cherry picked from commit 3f358213)
      3ab937bc
  2. May 02, 2016
  3. Apr 29, 2016
  4. Apr 27, 2016
  5. Apr 26, 2016
  6. Apr 25, 2016
  7. Apr 23, 2016
  8. Apr 22, 2016
  9. Apr 07, 2016
  10. Apr 04, 2016
  11. Mar 26, 2016
  12. Mar 18, 2016
  13. Mar 14, 2016
  14. Mar 09, 2016
  15. Mar 08, 2016
  16. Mar 07, 2016