1. 03 May, 2016 5 commits
    • Dmitry-Me's avatar
      Properly own the duplicated string · b7b8e948
      Dmitry-Me authored
      
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      b7b8e948
    • Dmitry-Me's avatar
      Improve comment · 399de496
      Dmitry-Me authored
      
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      399de496
    • Richard Levitte's avatar
    • Matt Caswell's avatar
      Prevent EBCDIC overread for very long strings · ea96ad5a
      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>
      ea96ad5a
    • Matt Caswell's avatar
      Fix encrypt overflow · 3f358213
      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>
      3f358213
  2. 02 May, 2016 14 commits
  3. 01 May, 2016 5 commits
  4. 29 Apr, 2016 16 commits