Skip to content
  1. Mar 01, 2016
    • Viktor Dukhovni's avatar
      Disable SSLv2 default build, default negotiation and weak ciphers. · 56f1acf5
      Viktor Dukhovni authored
      
      
      SSLv2 is by default disabled at build-time.  Builds that are not
      configured with "enable-ssl2" will not support SSLv2.  Even if
      "enable-ssl2" is used, users who want to negotiate SSLv2 via the
      version-flexible SSLv23_method() will need to explicitly call either
      of:
      
          SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
      or
          SSL_clear_options(ssl, SSL_OP_NO_SSLv2);
      
      as appropriate.  Even if either of those is used, or the application
      explicitly uses the version-specific SSLv2_method() or its client
      or server variants, SSLv2 ciphers vulnerable to exhaustive search
      key recovery have been removed.  Specifically, the SSLv2 40-bit
      EXPORT ciphers, and SSLv2 56-bit DES are no longer available.
      
      Mitigation for CVE-2016-0800
      
      Reviewed-by: default avatarEmilia Käsper <emilia@openssl.org>
      56f1acf5
  2. Feb 29, 2016
    • Matt Caswell's avatar
      Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption · 8f651326
      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>
      (cherry picked from commit c1753084)
      8f651326
  3. Feb 27, 2016
  4. Feb 25, 2016
    • Matt Caswell's avatar
      Fix memory issues in BIO_*printf functions · a801bf26
      Matt Caswell authored
      
      
      The internal |fmtstr| function used in processing a "%s" format string
      in the BIO_*printf functions could overflow while calculating the length
      of a string and cause an OOB read when printing very long strings.
      
      Additionally the internal |doapr_outch| function can attempt to write to
      an OOB memory location (at an offset from the NULL pointer) in the event of
      a memory allocation failure. In 1.0.2 and below this could be caused where
      the size of a buffer to be allocated is greater than INT_MAX. E.g. this
      could be in processing a very long "%s" format string. Memory leaks can also
      occur.
      
      These issues will only occur on certain platforms where sizeof(size_t) >
      sizeof(int). E.g. many 64 bit systems. The first issue may mask the second
      issue dependent on compiler behaviour.
      
      These problems could enable attacks where large amounts of untrusted data
      is passed to the BIO_*printf functions. If applications use these functions
      in this way then they could be vulnerable. OpenSSL itself uses these
      functions when printing out human-readable dumps of ASN.1 data. Therefore
      applications that print this data could be vulnerable if the data is from
      untrusted sources. OpenSSL command line applications could also be
      vulnerable where they print out ASN.1 data, or if untrusted data is passed
      as command line arguments.
      
      Libssl is not considered directly vulnerable. Additionally certificates etc
      received via remote connections via libssl are also unlikely to be able to
      trigger these issues because of message size limits enforced within libssl.
      
      CVE-2016-0799
      
      Issue reported by Guido Vranken.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      (cherry picked from commit 578b956f)
      a801bf26
    • Emilia Kasper's avatar
      CVE-2016-0798: avoid memory leak in SRP · 59a908f1
      Emilia Kasper authored
      
      
      The SRP user database lookup method SRP_VBASE_get_by_user had confusing
      memory management semantics; the returned pointer was sometimes newly
      allocated, and sometimes owned by the callee. The calling code has no
      way of distinguishing these two cases.
      
      Specifically, SRP servers that configure a secret seed to hide valid
      login information are vulnerable to a memory leak: an attacker
      connecting with an invalid username can cause a memory leak of around
      300 bytes per connection.
      
      Servers that do not configure SRP, or configure SRP but do not configure
      a seed are not vulnerable.
      
      In Apache, the seed directive is known as SSLSRPUnknownUserSeed.
      
      To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user
      is now disabled even if the user has configured a seed.
      
      Applications are advised to migrate to SRP_VBASE_get1_by_user. However,
      note that OpenSSL makes no strong guarantees about the
      indistinguishability of valid and invalid logins. In particular,
      computations are currently not carried out in constant time.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      59a908f1
  5. Feb 23, 2016
  6. Feb 19, 2016
  7. Feb 12, 2016
  8. Feb 11, 2016
  9. Feb 10, 2016
  10. Jan 28, 2016
  11. Jan 19, 2016
  12. Jan 17, 2016
  13. Jan 14, 2016
  14. Jan 10, 2016
  15. Jan 05, 2016
  16. Dec 28, 2015
  17. Dec 27, 2015
  18. Dec 22, 2015
  19. Dec 20, 2015
  20. Dec 19, 2015
  21. Dec 18, 2015