deps: upgrade openssl sources to 1.0.1u

This just replaces all sources of openssl-1.0.1u.tar.gz into deps/openssl/openssl. PR-URL: #8718 Reviewed-By: Fedor Indutny <[email protected]> Reviewed-By: Myles Borins <[email protected]>
nodejs · Sep 22, 2016 · 4a9da21 · 4a9da21
1 parent 1ba6d16
commit 4a9da21
Show file tree

Hide file tree

Showing 177 changed files with 1,651 additions and 38,121 deletions.
diff --git a/deps/openssl/openssl/CHANGES b/deps/openssl/openssl/CHANGES
@@ -2,6 +2,166 @@
  OpenSSL CHANGES
  _______________
 
+ Changes between 1.0.1t and 1.0.1u [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.1s and 1.0.1t [3 May 2016]
 
   *) Prevent padding oracle in AES-NI CBC MAC check
@@ -8195,7 +8355,7 @@ des-cbc           3624.96k     5258.21k     5530.91k     5624.30k     5628.26k
 
   *) Source code cleanups: use const where appropriate, eliminate casts,
      use void * instead of char * in lhash.
-     [Ulf Möller]
+     [Ulf Möller] 
 
   *) Bugfix: ssl3_send_server_key_exchange was not restartable
      (the state was not changed to SSL3_ST_SW_KEY_EXCH_B, and because of

diff --git a/deps/openssl/openssl/CONTRIBUTING b/deps/openssl/openssl/CONTRIBUTING
@@ -1,38 +1,75 @@
-HOW TO CONTRIBUTE TO OpenSSL
-----------------------------
+HOW TO CONTRIBUTE TO PATCHES OpenSSL
+------------------------------------
 
-Development is coordinated on the openssl-dev mailing list (see
-http://www.openssl.org for information on subscribing). If you
-would like to submit a patch, send it to [email protected] with
-the string "[PATCH]" in the subject. Please be sure to include a
-textual explanation of what your patch does.
-
-You can also make GitHub pull requests. If you do this, please also send
-mail to [email protected] with a brief description and a link to the PR so
-that we can more easily keep track of it.
+(Please visit https://www.openssl.org/community/getting-started.html for
+other ideas about how to contribute.)
 
+Development is coordinated on the openssl-dev mailing list (see the
+above link or https://mta.openssl.org for information on subscribing).
 If you are unsure as to whether a feature will be useful for the general
-OpenSSL community please discuss it on the openssl-dev mailing list first.
-Someone may be already working on the same thing or there may be a good
-reason as to why that feature isn't implemented.
+OpenSSL community you might want to discuss it on the openssl-dev mailing
+list first.  Someone may be already working on the same thing or there
+may be a good reason as to why that feature isn't implemented.
 
-Patches should be as up to date as possible, preferably relative to the
-current Git or the last snapshot. They should follow our coding style
-(see https://www.openssl.org/policies/codingstyle.html) and compile without
-warnings using the --strict-warnings flag.  OpenSSL compiles on many varied
-platforms: try to ensure you only use portable features.
+The best way to submit a patch is to make a pull request on GitHub.
+(It is not necessary to send mail to [email protected] to open a ticket!)
+If you think the patch could use feedback from the community, please
+start a thread on openssl-dev.
 
-Our preferred format for patch files is "git format-patch" output. For example
-to provide a patch file containing the last commit in your local git repository
-use the following command:
+You can also submit patches by sending it as mail to [email protected].
+Please include the word "PATCH" and an explanation of what the patch
+does in the subject line.  If you do this, our preferred format is "git
+format-patch" output. For example to provide a patch file containing the
+last commit in your local git repository use the following command:
 
-# git format-patch --stdout HEAD^ >mydiffs.patch
+    % git format-patch --stdout HEAD^ >mydiffs.patch
 
 Another method of creating an acceptable patch file without using git is as
 follows:
 
-# cd openssl-work
-# [your changes]
-# ./Configure dist; make clean
-# cd ..
-# diff -ur openssl-orig openssl-work > mydiffs.patch
+    % cd openssl-work
+    ...make your changes...
+    % ./Configure dist; make clean
+    % cd ..
+    % diff -ur openssl-orig openssl-work >mydiffs.patch
+
+Note that pull requests are generally easier for the team, and community, to
+work with.  Pull requests benefit from all of the standard GitHub features,
+including code review tools, simpler integration, and CI build support.
+
+No matter how a patch is submitted, the following items will help make
+the acceptance and review process faster:
+
+    1. Anything other than trivial contributions will require a contributor
+    licensing agreement, giving us permission to use your code. See
+    https://www.openssl.org/policies/cla.html for details.
+
+    2.  All source files should start with the following text (with
+    appropriate comment characters at the start of each line and the
+    year(s) updated):
+
+        Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
+
+        Licensed under the OpenSSL license (the "License").  You may not use
+        this file except in compliance with the License.  You can obtain a copy
+        in the file LICENSE in the source distribution or at
+        https://www.openssl.org/source/license.html
+
+    3.  Patches should be as current as possible.  When using GitHub, please
+    expect to have to rebase and update often. Note that we do not accept merge
+    commits. You will be asked to remove them before a patch is considered
+    acceptable.
+
+    4.  Patches should follow our coding style (see
+    https://www.openssl.org/policies/codingstyle.html) and compile without
+    warnings. Where gcc or clang is availble you should use the
+    --strict-warnings Configure option.  OpenSSL compiles on many varied
+    platforms: try to ensure you only use portable features.
+
+    5.  When at all possible, patches should include tests. These can either be
+    added to an existing test, or completely new.  Please see test/README
+    for information on the test framework.
+
+    6.  New features or changed functionality must include documentation. Please
+    look at the "pod" files in doc/apps, doc/crypto and doc/ssl for examples of
+    our style.
diff --git a/deps/openssl/openssl/Configure b/deps/openssl/openssl/Configure
@@ -741,7 +741,7 @@ my @experimental = ();
 
 # This is what $depflags will look like with the above defaults
 # (we need this to see if we should advise the user to run "make depend"):
-my $default_depflags = " -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST";
+my $default_depflags = " -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL2 -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS";
 
 # Explicit "no-..." options will be collected in %disabled along with the defaults.
 # To remove something from %disabled, use "enable-foo" (unless it's experimental).

diff --git a/deps/openssl/openssl/Makefile b/deps/openssl/openssl/Makefile
@@ -4,7 +4,7 @@
 ## Makefile for OpenSSL
 ##
 
-VERSION=1.0.1t
+VERSION=1.0.1u
 MAJOR=1
 MINOR=0.1
 SHLIB_VERSION_NUMBER=1.0.0

diff --git a/deps/openssl/openssl/Makefile.bak b/deps/openssl/openssl/Makefile.bak
@@ -4,7 +4,7 @@
 ## Makefile for OpenSSL
 ##
 
-VERSION=1.0.1t
+VERSION=1.0.1u
 MAJOR=1
 MINOR=0.1
 SHLIB_VERSION_NUMBER=1.0.0

diff --git a/deps/openssl/openssl/NEWS b/deps/openssl/openssl/NEWS
@@ -5,6 +5,20 @@
   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.1t and OpenSSL 1.0.1u [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.1s and OpenSSL 1.0.1t [3 May 2016]
 
       o Prevent padding oracle in AES-NI CBC MAC check (CVE-2016-2107)

diff --git a/deps/openssl/openssl/README b/deps/openssl/openssl/README
@@ -1,5 +1,5 @@
 
- OpenSSL 1.0.1t 3 May 2016
+ OpenSSL 1.0.1u 22 Sep 2016
 
  Copyright (c) 1998-2015 The OpenSSL Project
  Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson

diff --git a/deps/openssl/openssl/apps/app_rand.c b/deps/openssl/openssl/apps/app_rand.c
@@ -124,16 +124,10 @@ int app_RAND_load_file(const char *file, BIO *bio_e, int dont_warn)
     char buffer[200];
 
 #ifdef OPENSSL_SYS_WINDOWS
-    /*
-     * allocate 2 to dont_warn not to use RAND_screen() via
-     * -no_rand_screen option in s_client
-     */
-    if (dont_warn != 2) {
-      BIO_printf(bio_e, "Loading 'screen' into random state -");
-      BIO_flush(bio_e);
-      RAND_screen();
-      BIO_printf(bio_e, " done\n");
-    }
+    BIO_printf(bio_e, "Loading 'screen' into random state -");
+    BIO_flush(bio_e);
+    RAND_screen();
+    BIO_printf(bio_e, " done\n");
 #endif
 
     if (file == NULL)

diff --git a/deps/openssl/openssl/apps/apps.c b/deps/openssl/openssl/apps/apps.c
@@ -2241,6 +2241,8 @@ int args_verify(char ***pargs, int *pargc,
         flags |= X509_V_FLAG_CHECK_SS_SIGNATURE;
     else if (!strcmp(arg, "-no_alt_chains"))
         flags |= X509_V_FLAG_NO_ALT_CHAINS;
+    else if (!strcmp(arg, "-allow_proxy_certs"))
+        flags |= X509_V_FLAG_ALLOW_PROXY_CERTS;
     else
         return 0;
 

diff --git a/deps/openssl/openssl/apps/enc.c b/deps/openssl/openssl/apps/enc.c
@@ -509,7 +509,7 @@ int MAIN(int argc, char **argv)
                             BIO_printf(bio_err, "invalid hex salt value\n");
                             goto end;
                         }
-                    } else if (RAND_pseudo_bytes(salt, sizeof salt) < 0)
+                    } else if (RAND_bytes(salt, sizeof salt) <= 0)
                         goto end;
                     /*
                      * If -P option then don't bother writing

diff --git a/deps/openssl/openssl/apps/passwd.c b/deps/openssl/openssl/apps/passwd.c
@@ -416,7 +416,7 @@ static int do_passwd(int passed_salt, char **salt_p, char **salt_malloc_p,
                 if (*salt_malloc_p == NULL)
                     goto err;
             }
-            if (RAND_pseudo_bytes((unsigned char *)*salt_p, 2) < 0)
+            if (RAND_bytes((unsigned char *)*salt_p, 2) <= 0)
                 goto err;
             (*salt_p)[0] = cov_2char[(*salt_p)[0] & 0x3f]; /* 6 bits */
             (*salt_p)[1] = cov_2char[(*salt_p)[1] & 0x3f]; /* 6 bits */
@@ -437,7 +437,7 @@ static int do_passwd(int passed_salt, char **salt_p, char **salt_malloc_p,
                 if (*salt_malloc_p == NULL)
                     goto err;
             }
-            if (RAND_pseudo_bytes((unsigned char *)*salt_p, 8) < 0)
+            if (RAND_bytes((unsigned char *)*salt_p, 8) <= 0)
                 goto err;
 
             for (i = 0; i < 8; i++)