1. 22 Apr, 2016 1 commit
  2. 07 Apr, 2016 2 commits
  3. 04 Apr, 2016 1 commit
  4. 26 Mar, 2016 1 commit
  5. 18 Mar, 2016 4 commits
  6. 14 Mar, 2016 1 commit
  7. 09 Mar, 2016 3 commits
  8. 08 Mar, 2016 1 commit
  9. 07 Mar, 2016 4 commits
  10. 04 Mar, 2016 1 commit
    • Dr. Stephen Henson's avatar
      Sanity check PVK file fields. · df14e502
      Dr. Stephen Henson authored
      
      
      PVK files with abnormally large length or salt fields can cause an
      integer overflow which can result in an OOB read and heap corruption.
      However this is an rarely used format and private key files do not
      normally come from untrusted sources the security implications not
      significant.
      
      Fix by limiting PVK length field to 100K and salt to 10K: these should be
      more than enough to cover any files encountered in practice.
      
      Issue reported by Guido Vranken.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit 5f57abe2)
      df14e502
  11. 01 Mar, 2016 15 commits
  12. 29 Feb, 2016 1 commit
    • Matt Caswell's avatar
      Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption · c1753084
      Matt Caswell authored
      
      
      In the BN_hex2bn function the number of hex digits is calculated using
      an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
      For large values of |i| this can result in |bn_expand| not allocating any
      memory because |i * 4| is negative. This leaves ret->d as NULL leading
      to a subsequent NULL ptr deref. For very large values of |i|, the
      calculation |i * 4| could be a positive value smaller than |i|. In this
      case memory is allocated to ret->d, but it is insufficiently sized
      leading to heap corruption. A similar issue exists in BN_dec2bn.
      
      This could have security consequences if BN_hex2bn/BN_dec2bn is ever
      called by user applications with very large untrusted hex/dec data. This is
      anticipated to be a rare occurrence.
      
      All OpenSSL internal usage of this function uses data that is not expected
      to be untrusted, e.g. config file data or application command line
      arguments. If user developed applications generate config file data based
      on untrusted data then it is possible that this could also lead to security
      consequences. This is also anticipated to be a rare.
      
      Issue reported by Guido Vranken.
      
      CVE-2016-0797
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      c1753084
  13. 28 Feb, 2016 1 commit
  14. 27 Feb, 2016 4 commits