Skip to content
  1. Apr 26, 2016
  2. Apr 25, 2016
  3. Apr 23, 2016
  4. Apr 22, 2016
  5. Apr 07, 2016
  6. Apr 04, 2016
  7. Mar 26, 2016
  8. Mar 18, 2016
  9. Mar 14, 2016
  10. Mar 09, 2016
  11. Mar 08, 2016
  12. Mar 07, 2016
  13. Mar 04, 2016
    • 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
  14. Mar 01, 2016
  15. Feb 29, 2016
    • 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