Skip to content
  1. Aug 25, 2015
  2. Aug 17, 2015
  3. Aug 16, 2015
  4. Aug 14, 2015
  5. Aug 12, 2015
  6. Aug 11, 2015
    • Matt Caswell's avatar
      Fix "make test" seg fault with SCTP enabled · 396e3004
      Matt Caswell authored
      
      
      When config'd with "sctp" running "make test" causes a seg fault. This is
      actually due to the way ssltest works - it dives under the covers and frees
      up BIOs manually and so some BIOs are NULL when the SCTP code does not
      expect it. The simplest fix is just to add some sanity checks to make sure
      the BIOs aren't NULL before we use them.
      
      This problem occurs in master and 1.0.2. The fix has also been applied to
      1.0.1 to keep the code in sync.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      (cherry picked from commit f75d5171)
      396e3004
    • Matt Caswell's avatar
      Fix missing return value checks in SCTP · 402634f8
      Matt Caswell authored
      
      
      There are some missing return value checks in the SCTP code. In master this
      was causing a compilation failure when config'd with
      "--strict-warnings sctp".
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      (cherry picked from commit d8e8590e)
      402634f8
    • Matt Caswell's avatar
      Check for 0 modulus in BN_MONT_CTX_set · b11980d7
      Matt Caswell authored
      
      
      The function BN_MONT_CTX_set was assuming that the modulus was non-zero
      and therefore that |mod->top| > 0. In an error situation that may not be
      the case and could cause a seg fault.
      
      This is a follow on from CVE-2015-1794.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      b11980d7
    • Guy Leaver (guleaver)'s avatar
      Fix seg fault with 0 p val in SKE · f15c99f4
      Guy Leaver (guleaver) authored
      
      
      If a client receives a ServerKeyExchange for an anon DH ciphersuite with the
      value of p set to 0 then a seg fault can occur. This commits adds a test to
      reject p, g and pub key parameters that have a 0 value (in accordance with
      RFC 5246)
      
      The security vulnerability only affects master and 1.0.2, but the fix is
      additionally applied to 1.0.1 for additional confidence.
      
      CVE-2015-1794
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      f15c99f4
  7. Aug 04, 2015
  8. Aug 01, 2015
  9. Jul 31, 2015
  10. Jul 30, 2015
  11. Jul 29, 2015
  12. Jul 27, 2015
    • Matt Caswell's avatar
      Fix SSL_set_session_ticket_ext when used with SSLv23_method · 728432ae
      Matt Caswell authored
      
      
      The function SSL_set_session_ticket_ext can be used to set custom session
      ticket data passed in the initial ClientHello. This can be particularly
      useful for EAP-FAST. However, when using SSLv23_method, the session does
      not get created until the ServerHello has been received. The extension code
      will only add the SessionTicket data to the ClientHello if a session already
      exists. Therefore SSL_set_session_ticket_ext has no impact when used in
      conjunction with SSLv23_method. The solution is to simply create the session
      during creation of the ClientHello instead of waiting for the ServerHello.
      
      This commit fixes the test failure introduced by the previous commit.
      
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      728432ae
    • Matt Caswell's avatar
      Add test for SSL_set_session_ticket_ext · 8e75dcf5
      Matt Caswell authored
      
      
      The function SSL_set_session_ticket_ext sets the ticket data to be sent in
      the ClientHello. This is useful for EAP-FAST. This commit adds a test to
      ensure that when this function is called the expected ticket data actually
      appears in the ClientHello.
      
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      8e75dcf5
  13. Jul 15, 2015
  14. Jul 14, 2015
  15. Jul 13, 2015
  16. Jul 10, 2015
  17. Jul 09, 2015
  18. Jul 07, 2015
    • Matt Caswell's avatar
      Fix alt chains bug · cb22d2ae
      Matt Caswell authored
      
      
      This is a follow up to the alternate chains certificate forgery issue
      (CVE-2015-1793). That issue is exacerbated in 1.0.1 by a related bug which
      means that we *always* check for an alternative chain, even if we have
      already found a chain. The code is supposed to stop as soon as it has found
      one (and does do in master and 1.0.2).
      
      Reviewed-by: default avatarStephen Henson <steve@openssl.org>
      cb22d2ae
    • Matt Caswell's avatar
      Reject calls to X509_verify_cert that have not been reinitialised · b3b1eb57
      Matt Caswell authored
      
      
      The function X509_verify_cert checks the value of |ctx->chain| at the
      beginning, and if it is NULL then it initialises it, along with the value
      of ctx->untrusted. The normal way to use X509_verify_cert() is to first
      call X509_STORE_CTX_init(); then set up various parameters etc; then call
      X509_verify_cert(); then check the results; and finally call
      X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
      |ctx->chain| to NULL. The only place in the OpenSSL codebase  where
      |ctx->chain| is set to anything other than a non NULL value is in
      X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
      non NULL on entry to X509_verify_cert is if one of the following occurs:
      1) An application calls X509_verify_cert() twice without re-initialising
      in between.
      2) An application reaches inside the X509_STORE_CTX structure and changes
      the value of |ctx->chain| directly.
      
      With regards to the second of these, we should discount this - it should
      not be supported to allow this.
      
      With regards to the first of these, the documentation is not exactly
      crystal clear, but the implication is that you must call
      X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
      to do this then, at best, the results would be undefined.
      
      Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
      likely to have unexpected results, and could be dangerous. This commit
      changes the behaviour of X509_verify_cert() so that it causes an error if
      |ctx->chain| is anything other than NULL (because this indicates that we
      have not been initialised properly). It also clarifies the associated
      documentation. This is a follow up commit to CVE-2015-1793.
      
      Reviewed-by: default avatarStephen Henson <steve@openssl.org>
      b3b1eb57
    • Matt Caswell's avatar
      Add test for CVE-2015-1793 · d42d1004
      Matt Caswell authored
      
      
      This adds a test for CVE-2015-1793. This adds a new test file
      verify_extra_test.c, which could form the basis for additional
      verification tests.
      
      Reviewed-by: default avatarStephen Henson <steve@openssl.org>
      
      Conflicts:
      	test/Makefile
      d42d1004
    • Matt Caswell's avatar
      Fix alternate chains certificate forgery issue · 9a0db453
      Matt Caswell authored
      
      
      During certificate verfification, OpenSSL will attempt to find an
      alternative certificate chain if the first attempt to build such a chain
      fails. An error in the implementation of this logic can mean that an
      attacker could cause certain checks on untrusted certificates to be
      bypassed, such as the CA flag, enabling them to use a valid leaf
      certificate to act as a CA and "issue" an invalid certificate.
      
      This occurs where at least one cert is added to the first chain from the
      trust store, but that chain still ends up being untrusted. In that case
      ctx->last_untrusted is decremented in error.
      
      Patch provided by the BoringSSL project.
      
      CVE-2015-1793
      
      Reviewed-by: default avatarStephen Henson <steve@openssl.org>
      9a0db453
  19. Jul 06, 2015