Skip to content
  1. Feb 27, 2016
  2. 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
  3. Feb 23, 2016
  4. Feb 19, 2016
  5. Feb 12, 2016
  6. Feb 11, 2016
  7. Feb 10, 2016
  8. Jan 28, 2016
  9. Jan 19, 2016
  10. Jan 17, 2016
  11. Jan 14, 2016
  12. Jan 10, 2016
  13. Jan 05, 2016
  14. Dec 28, 2015
  15. Dec 27, 2015
  16. Dec 22, 2015
  17. Dec 20, 2015
  18. Dec 19, 2015
  19. Dec 18, 2015
  20. Dec 16, 2015
  21. Dec 14, 2015