The branch OpenSSL_1_0_2-stable has been updated
       via  9d264d11a93413d2724b7c8c873e56b2ddd8c53f (commit)
       via  32c130160f7dac2cef5d0e30d94b335e4a87104d (commit)
       via  35aede1cd7411aa404512facfcb22e3859966ef6 (commit)
       via  92c8d6ae0d741fdca3b72baf627d16908dae64ce (commit)
       via  38f59bd1f1da9f5ef67044b35af26528e5b183dd (commit)
       via  ea39b16b71e4e72a228a4535bd6d6a02c5edbc1f (commit)
      from  90d6f35162a9515287e75248e1f880cd1cc92c1f (commit)


- Log -----------------------------------------------------------------
commit 9d264d11a93413d2724b7c8c873e56b2ddd8c53f
Author: Matt Caswell <m...@openssl.org>
Date:   Thu Sep 22 11:25:49 2016 +0100

    Prepare for 1.0.2j-dev
    
    Reviewed-by: Richard Levitte <levi...@openssl.org>

commit 32c130160f7dac2cef5d0e30d94b335e4a87104d
Author: Matt Caswell <m...@openssl.org>
Date:   Thu Sep 22 11:24:53 2016 +0100

    Prepare for 1.0.2i release
    
    Reviewed-by: Richard Levitte <levi...@openssl.org>

commit 35aede1cd7411aa404512facfcb22e3859966ef6
Author: Matt Caswell <m...@openssl.org>
Date:   Wed Sep 21 21:59:49 2016 +0100

    Updates CHANGES and NEWS for new release
    
    Reviewed-by: Richard Levitte <levi...@openssl.org>

commit 92c8d6ae0d741fdca3b72baf627d16908dae64ce
Author: Dmitry Belyavsky <beld...@gmail.com>
Date:   Mon Sep 19 16:05:53 2016 +0100

    Avoid KCI attack for GOST
    
    Russian GOST ciphersuites are vulnerable to the KCI attack because they use
    long-term keys to establish the connection when ssl client authorization is
    on. This change brings the GOST implementation into line with the latest
    specs in order to avoid the attack. It should not break backwards
    compatibility.
    
    Reviewed-by: Rich Salz <rs...@openssl.org>
    Reviewed-by: Richard Levitte <levi...@openssl.org>
    Reviewed-by: Matt Caswell <m...@openssl.org>

commit 38f59bd1f1da9f5ef67044b35af26528e5b183dd
Author: Matt Caswell <m...@openssl.org>
Date:   Fri Sep 9 10:53:39 2016 +0100

    Fix a mem leak in NPN handling
    
    If a server sent multiple NPN extensions in a single ClientHello then a
    mem leak can occur. This will only happen where the client has requested
    NPN in the first place. It does not occur during renegotiation. Therefore
    the maximum that could be leaked in a single connection with a malicious
    server is 64k (the maximum size of the ServerHello extensions section). As
    this is client side, only occurs if NPN has been requested and does not
    occur during renegotiation this is unlikely to be exploitable.
    
    Issue reported by Shi Lei.
    
    Reviewed-by: Rich Salz <rs...@openssl.org>

commit ea39b16b71e4e72a228a4535bd6d6a02c5edbc1f
Author: Matt Caswell <m...@openssl.org>
Date:   Fri Sep 9 10:08:45 2016 +0100

    Fix OCSP Status Request extension unbounded memory growth
    
    A malicious client can send an excessively large OCSP Status Request
    extension. If that client continually requests renegotiation,
    sending a large OCSP Status Request extension each time, then there will
    be unbounded memory growth on the server. This will eventually lead to a
    Denial Of Service attack through memory exhaustion. Servers with a
    default configuration are vulnerable even if they do not support OCSP.
    Builds using the "no-ocsp" build time option are not affected.
    
    I have also checked other extensions to see if they suffer from a similar
    problem but I could not find any other issues.
    
    CVE-2016-6304
    
    Issue reported by Shi Lei.
    
    Reviewed-by: Rich Salz <rs...@openssl.org>

-----------------------------------------------------------------------

Summary of changes:
 CHANGES           | 162 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
 NEWS              |  16 +++++-
 README            |   2 +-
 crypto/opensslv.h |   6 +-
 openssl.spec      |   2 +-
 ssl/s3_clnt.c     |  19 -------
 ssl/t1_lib.c      |  29 +++++++---
 7 files changed, 201 insertions(+), 35 deletions(-)

diff --git a/CHANGES b/CHANGES
index 6502fc3..c072379 100644
--- a/CHANGES
+++ b/CHANGES
@@ -2,14 +2,170 @@
  OpenSSL CHANGES
  _______________
 
- Changes between 1.0.2h and 1.0.2i [xx XXX xxxx]
+ Changes between 1.0.2i and 1.0.2j [xx XXX xxxx]
 
   *)
 
-  *) In order to mitigate the SWEET32 attack (CVE-2016-2183),
-     the DES ciphers were moved from HIGH to MEDIUM.
+ Changes between 1.0.2h and 1.0.2i [22 Sep 2016]
+
+  *) OCSP Status Request extension unbounded memory growth
+
+     A malicious client can send an excessively large OCSP Status Request
+     extension. If that client continually requests renegotiation, sending a
+     large OCSP Status Request extension each time, then there will be 
unbounded
+     memory growth on the server. This will eventually lead to a Denial Of
+     Service attack through memory exhaustion. Servers with a default
+     configuration are vulnerable even if they do not support OCSP. Builds 
using
+     the "no-ocsp" build time option are not affected.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6304)
+     [Matt Caswell]
+
+  *) In order to mitigate the SWEET32 attack, the DES ciphers were moved from
+     HIGH to MEDIUM.
+
+     This issue was reported to OpenSSL Karthikeyan Bhargavan and Gaetan
+     Leurent (INRIA)
+     (CVE-2016-2183)
      [Rich Salz]
 
+  *) OOB write in MDC2_Update()
+
+     An overflow can occur in MDC2_Update() either if called directly or
+     through the EVP_DigestUpdate() function using MDC2. If an attacker
+     is able to supply very large amounts of input data after a previous
+     call to EVP_EncryptUpdate() with a partial block then a length check
+     can overflow resulting in a heap corruption.
+
+     The amount of data needed is comparable to SIZE_MAX which is impractical
+     on most platforms.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6303)
+     [Stephen Henson]
+
+  *) Malformed SHA512 ticket DoS
+
+     If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a
+     DoS attack where a malformed ticket will result in an OOB read which will
+     ultimately crash.
+
+     The use of SHA512 in TLS session tickets is comparatively rare as it 
requires
+     a custom server callback and ticket lookup mechanism.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6302)
+     [Stephen Henson]
+
+  *) OOB write in BN_bn2dec()
+
+     The function BN_bn2dec() does not check the return value of BN_div_word().
+     This can cause an OOB write if an application uses this function with an
+     overly large BIGNUM. This could be a problem if an overly large 
certificate
+     or CRL is printed out from an untrusted source. TLS is not affected 
because
+     record limits will reject an oversized certificate before it is parsed.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-2182)
+     [Stephen Henson]
+
+  *) OOB read in TS_OBJ_print_bio()
+
+     The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is
+     the total length the OID text representation would use and not the amount
+     of data written. This will result in OOB reads when large OIDs are
+     presented.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-2180)
+     [Stephen Henson]
+
+  *) Pointer arithmetic undefined behaviour
+
+     Avoid some undefined pointer arithmetic
+
+     A common idiom in the codebase is to check limits in the following manner:
+     "p + len > limit"
+
+     Where "p" points to some malloc'd data of SIZE bytes and
+     limit == p + SIZE
+
+     "len" here could be from some externally supplied data (e.g. from a TLS
+     message).
+
+     The rules of C pointer arithmetic are such that "p + len" is only well
+     defined where len <= SIZE. Therefore the above idiom is actually
+     undefined behaviour.
+
+     For example this could cause problems if some malloc implementation
+     provides an address for "p" such that "p + len" actually overflows for
+     values of len that are too big and therefore p + len < limit.
+
+     This issue was reported to OpenSSL by Guido Vranken
+     (CVE-2016-2177)
+     [Matt Caswell]
+
+  *) Constant time flag not preserved in DSA signing
+
+     Operations in the DSA signing algorithm should run in constant time in
+     order to avoid side channel attacks. A flaw in the OpenSSL DSA
+     implementation means that a non-constant time codepath is followed for
+     certain operations. This has been demonstrated through a cache-timing
+     attack to be sufficient for an attacker to recover the private DSA key.
+
+     This issue was reported by César Pereida (Aalto University), Billy Brumley
+     (Tampere University of Technology), and Yuval Yarom (The University of
+     Adelaide and NICTA).
+     (CVE-2016-2178)
+     [César Pereida]
+
+  *) DTLS buffered message DoS
+
+     In a DTLS connection where handshake messages are delivered out-of-order
+     those messages that OpenSSL is not yet ready to process will be buffered
+     for later use. Under certain circumstances, a flaw in the logic means that
+     those messages do not get removed from the buffer even though the 
handshake
+     has been completed. An attacker could force up to approx. 15 messages to
+     remain in the buffer when they are no longer required. These messages will
+     be cleared when the DTLS connection is closed. The default maximum size 
for
+     a message is 100k. Therefore the attacker could force an additional 1500k
+     to be consumed per connection. By opening many simulataneous connections 
an
+     attacker could cause a DoS attack through memory exhaustion.
+
+     This issue was reported to OpenSSL by Quan Luo.
+     (CVE-2016-2179)
+     [Matt Caswell]
+
+  *) DTLS replay protection DoS
+
+     A flaw in the DTLS replay attack protection mechanism means that records
+     that arrive for future epochs update the replay protection "window" before
+     the MAC for the record has been validated. This could be exploited by an
+     attacker by sending a record for the next epoch (which does not have to
+     decrypt or have a valid MAC), with a very large sequence number. This 
means
+     that all subsequent legitimate packets are dropped causing a denial of
+     service for a specific DTLS connection.
+
+     This issue was reported to OpenSSL by the OCAP audit team.
+     (CVE-2016-2181)
+     [Matt Caswell]
+
+  *) Certificate message OOB reads
+
+     In OpenSSL 1.0.2 and earlier some missing message length checks can result
+     in OOB reads of up to 2 bytes beyond an allocated buffer. There is a
+     theoretical DoS risk but this has not been observed in practice on common
+     platforms.
+
+     The messages affected are client certificate, client certificate request
+     and server certificate. As a result the attack can only be performed
+     against a client or a server which enables client authentication.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6306)
+     [Stephen Henson]
+
  Changes between 1.0.2g and 1.0.2h [3 May 2016]
 
   *) Prevent padding oracle in AES-NI CBC MAC check
diff --git a/NEWS b/NEWS
index 1d59f3e..6a787e6 100644
--- a/NEWS
+++ b/NEWS
@@ -5,10 +5,24 @@
   This file gives a brief overview of the major changes between each OpenSSL
   release. For more details please read the CHANGES file.
 
-  Major changes between OpenSSL 1.0.2h and OpenSSL 1.0.2i [under development]
+  Major changes between OpenSSL 1.0.2i and OpenSSL 1.0.2j [under development]
 
       o
 
+  Major changes between OpenSSL 1.0.2h and OpenSSL 1.0.2i [22 Sep 2016]
+
+      o OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
+      o SWEET32 Mitigation (CVE-2016-2183)
+      o OOB write in MDC2_Update() (CVE-2016-6303)
+      o Malformed SHA512 ticket DoS (CVE-2016-6302)
+      o OOB write in BN_bn2dec() (CVE-2016-2182)
+      o OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
+      o Pointer arithmetic undefined behaviour (CVE-2016-2177)
+      o Constant time flag not preserved in DSA signing (CVE-2016-2178)
+      o DTLS buffered message DoS (CVE-2016-2179)
+      o DTLS replay protection DoS (CVE-2016-2181)
+      o Certificate message OOB reads (CVE-2016-6306)
+
   Major changes between OpenSSL 1.0.2g and OpenSSL 1.0.2h [3 May 2016]
 
       o Prevent padding oracle in AES-NI CBC MAC check (CVE-2016-2107)
diff --git a/README b/README
index a065f68..9cba523 100644
--- a/README
+++ b/README
@@ -1,5 +1,5 @@
 
- OpenSSL 1.0.2i-dev
+ OpenSSL 1.0.2j-dev
 
  Copyright (c) 1998-2015 The OpenSSL Project
  Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
diff --git a/crypto/opensslv.h b/crypto/opensslv.h
index 2db36ac..c40160b 100644
--- a/crypto/opensslv.h
+++ b/crypto/opensslv.h
@@ -30,11 +30,11 @@ extern "C" {
  * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
  *  major minor fix final patch/beta)
  */
-# define OPENSSL_VERSION_NUMBER  0x10002090L
+# define OPENSSL_VERSION_NUMBER  0x100020a0L
 # ifdef OPENSSL_FIPS
-#  define OPENSSL_VERSION_TEXT    "OpenSSL 1.0.2i-fips-dev  xx XXX xxxx"
+#  define OPENSSL_VERSION_TEXT    "OpenSSL 1.0.2j-fips-dev  xx XXX xxxx"
 # else
-#  define OPENSSL_VERSION_TEXT    "OpenSSL 1.0.2i-dev  xx XXX xxxx"
+#  define OPENSSL_VERSION_TEXT    "OpenSSL 1.0.2j-dev  xx XXX xxxx"
 # endif
 # define OPENSSL_VERSION_PTEXT   " part of " OPENSSL_VERSION_TEXT
 
diff --git a/openssl.spec b/openssl.spec
index e4bf1b7..880a5c3 100644
--- a/openssl.spec
+++ b/openssl.spec
@@ -7,7 +7,7 @@ Release: 1
 
 Summary: Secure Sockets Layer and cryptography libraries and tools
 Name: openssl
-Version: 1.0.2i
+Version: 1.0.2j
 Source0: ftp://ftp.openssl.org/source/%{name}-%{version}.tar.gz
 License: OpenSSL
 Group: System Environment/Libraries
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index d2afaa5..2185347 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -3014,19 +3014,6 @@ int ssl3_send_client_key_exchange(SSL *s)
                 goto err;
             }
             /*
-             * If we have client certificate, use its secret as peer key
-             */
-            if (s->s3->tmp.cert_req && s->cert->key->privatekey) {
-                if (EVP_PKEY_derive_set_peer
-                    (pkey_ctx, s->cert->key->privatekey) <= 0) {
-                    /*
-                     * If there was an error - just ignore it. Ephemeral key
-                     * * would be used
-                     */
-                    ERR_clear_error();
-                }
-            }
-            /*
              * Compute shared IV and store it in algorithm-specific context
              * data
              */
@@ -3072,12 +3059,6 @@ int ssl3_send_client_key_exchange(SSL *s)
                 n = msglen + 2;
             }
             memcpy(p, tmp, msglen);
-            /* Check if pubkey from client certificate was used */
-            if (EVP_PKEY_CTX_ctrl
-                (pkey_ctx, -1, -1, EVP_PKEY_CTRL_PEER_KEY, 2, NULL) > 0) {
-                /* Set flag "skip certificate verify" */
-                s->s3->flags |= TLS1_FLAGS_SKIP_CERT_VERIFY;
-            }
             EVP_PKEY_CTX_free(pkey_ctx);
             s->session->master_key_length =
                 s->method->ssl3_enc->generate_master_secret(s,
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index fbcf2e6..7831046 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -2316,6 +2316,23 @@ static int ssl_scan_clienthello_tlsext(SSL *s, unsigned 
char **p,
                 size -= 2;
                 if (dsize > size)
                     goto err;
+
+                /*
+                 * We remove any OCSP_RESPIDs from a previous handshake
+                 * to prevent unbounded memory growth - CVE-2016-6304
+                 */
+                sk_OCSP_RESPID_pop_free(s->tlsext_ocsp_ids,
+                                        OCSP_RESPID_free);
+                if (dsize > 0) {
+                    s->tlsext_ocsp_ids = sk_OCSP_RESPID_new_null();
+                    if (s->tlsext_ocsp_ids == NULL) {
+                        *al = SSL_AD_INTERNAL_ERROR;
+                        return 0;
+                    }
+                } else {
+                    s->tlsext_ocsp_ids = NULL;
+                }
+
                 while (dsize > 0) {
                     OCSP_RESPID *id;
                     int idsize;
@@ -2335,13 +2352,6 @@ static int ssl_scan_clienthello_tlsext(SSL *s, unsigned 
char **p,
                         OCSP_RESPID_free(id);
                         goto err;
                     }
-                    if (!s->tlsext_ocsp_ids
-                        && !(s->tlsext_ocsp_ids =
-                             sk_OCSP_RESPID_new_null())) {
-                        OCSP_RESPID_free(id);
-                        *al = SSL_AD_INTERNAL_ERROR;
-                        return 0;
-                    }
                     if (!sk_OCSP_RESPID_push(s->tlsext_ocsp_ids, id)) {
                         OCSP_RESPID_free(id);
                         *al = SSL_AD_INTERNAL_ERROR;
@@ -2712,6 +2722,11 @@ static int ssl_scan_serverhello_tlsext(SSL *s, unsigned 
char **p,
                 *al = TLS1_AD_INTERNAL_ERROR;
                 return 0;
             }
+            /*
+             * Could be non-NULL if server has sent multiple NPN extensions in
+             * a single Serverhello
+             */
+            OPENSSL_free(s->next_proto_negotiated);
             s->next_proto_negotiated = OPENSSL_malloc(selected_len);
             if (!s->next_proto_negotiated) {
                 *al = TLS1_AD_INTERNAL_ERROR;
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits

Reply via email to