diff options
author | sangsu <sangsu.choi@samsung.com> | 2016-03-07 14:42:53 +0900 |
---|---|---|
committer | sangsu <sangsu.choi@samsung.com> | 2016-03-07 15:23:22 +0900 |
commit | f7c7a1e422ab564e8edea168476eb83f867c1c49 (patch) | |
tree | 3b015105d1dca6fafc36bdbc5b86abeddde8f489 /CHANGES | |
parent | 2b3ef38d58c1bb0abff4bf611177fc76e78325fa (diff) | |
download | openssl-f7c7a1e422ab564e8edea168476eb83f867c1c49.tar.gz openssl-f7c7a1e422ab564e8edea168476eb83f867c1c49.tar.bz2 openssl-f7c7a1e422ab564e8edea168476eb83f867c1c49.zip |
Imported Upstream version 1.0.2gupstream/1.0.2g
Change-Id: I2b5f4248ba97b6abbe363a5da33c953e623e0a7e
Signed-off-by: sangsu <sangsu.choi@samsung.com>
Diffstat (limited to 'CHANGES')
-rw-r--r-- | CHANGES | 182 |
1 files changed, 181 insertions, 1 deletions
@@ -2,6 +2,186 @@ OpenSSL CHANGES _______________ + Changes between 1.0.2f and 1.0.2g [1 Mar 2016] + + * Disable weak ciphers in SSLv3 and up in default builds of OpenSSL. + Builds that are not configured with "enable-weak-ssl-ciphers" will not + provide any "EXPORT" or "LOW" strength ciphers. + [Viktor Dukhovni] + + * Disable SSLv2 default build, default negotiation and weak ciphers. 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 and + 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. + (CVE-2016-0800) + [Viktor Dukhovni] + + *) Fix a double-free in DSA code + + A double free bug was discovered when OpenSSL parses malformed DSA private + keys and could lead to a DoS attack or memory corruption for applications + that receive DSA private keys from untrusted sources. This scenario is + considered rare. + + This issue was reported to OpenSSL by Adam Langley(Google/BoringSSL) using + libFuzzer. + (CVE-2016-0705) + [Stephen Henson] + + *) Disable SRP fake user seed to address a server memory leak. + + Add a new method SRP_VBASE_get1_by_user that handles the seed properly. + + SRP_VBASE_get_by_user had inconsistent memory management behaviour. + In order to fix an unavoidable memory leak, SRP_VBASE_get_by_user + was changed to ignore the "fake user" SRP seed, even if the seed + is configured. + + Users should use SRP_VBASE_get1_by_user instead. Note that in + SRP_VBASE_get1_by_user, caller must free the returned value. Note + also that even though configuring the SRP seed attempts to hide + invalid usernames by continuing the handshake with fake + credentials, this behaviour is not constant time and no strong + guarantees are made that the handshake is indistinguishable from + that of a valid user. + (CVE-2016-0798) + [Emilia Käsper] + + *) Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption + + 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 can leave the internal BIGNUM data + field 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 the internal BIGNUM data field, 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 these functions use 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 rare. + + This issue was reported to OpenSSL by Guido Vranken. + (CVE-2016-0797) + [Matt Caswell] + + *) Fix memory issues in BIO_*printf functions + + 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. + + 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. + + This issue was reported to OpenSSL Guido Vranken. + (CVE-2016-0799) + [Matt Caswell] + + *) Side channel attack on modular exponentiation + + A side-channel attack was found which makes use of cache-bank conflicts on + the Intel Sandy-Bridge microarchitecture which could lead to the recovery + of RSA keys. The ability to exploit this issue is limited as it relies on + an attacker who has control of code in a thread running on the same + hyper-threaded core as the victim thread which is performing decryptions. + + This issue was reported to OpenSSL by Yuval Yarom, The University of + Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and + Nadia Heninger, University of Pennsylvania with more information at + http://cachebleed.info. + (CVE-2016-0702) + [Andy Polyakov] + + *) Change the req app to generate a 2048-bit RSA/DSA key by default, + if no keysize is specified with default_bits. This fixes an + omission in an earlier change that changed all RSA/DSA key generation + apps to use 2048 bits by default. + [Emilia Käsper] + + Changes between 1.0.2e and 1.0.2f [28 Jan 2016] + + *) DH small subgroups + + Historically OpenSSL only ever generated DH parameters based on "safe" + primes. More recently (in version 1.0.2) support was provided for + generating X9.42 style parameter files such as those required for RFC 5114 + support. The primes used in such files may not be "safe". Where an + application is using DH configured with parameters based on primes that are + not "safe" then an attacker could use this fact to find a peer's private + DH exponent. This attack requires that the attacker complete multiple + handshakes in which the peer uses the same private DH exponent. For example + this could be used to discover a TLS server's private DH exponent if it's + reusing the private DH exponent or it's using a static DH ciphersuite. + + OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in + TLS. It is not on by default. If the option is not set then the server + reuses the same private DH exponent for the life of the server process and + would be vulnerable to this attack. It is believed that many popular + applications do set this option and would therefore not be at risk. + + The fix for this issue adds an additional check where a "q" parameter is + available (as is the case in X9.42 based parameters). This detects the + only known attack, and is the only possible defense for static DH + ciphersuites. This could have some performance impact. + + Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by + default and cannot be disabled. This could have some performance impact. + + This issue was reported to OpenSSL by Antonio Sanso (Adobe). + (CVE-2016-0701) + [Matt Caswell] + + *) SSLv2 doesn't block disabled ciphers + + A malicious client can negotiate SSLv2 ciphers that have been disabled on + the server and complete SSLv2 handshakes even if all SSLv2 ciphers have + been disabled, provided that the SSLv2 protocol was not also disabled via + SSL_OP_NO_SSLv2. + + This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram + and Sebastian Schinzel. + (CVE-2015-3197) + [Viktor Dukhovni] + + *) Reject DH handshakes with parameters shorter than 1024 bits. + [Kurt Roeckx] + Changes between 1.0.2d and 1.0.2e [3 Dec 2015] *) BN_mod_exp may produce incorrect results on x86_64 @@ -57,7 +237,7 @@ [Emilia Käsper] *) In DSA_generate_parameters_ex, if the provided seed is too short, - return an error + use a random seed, as already documented. [Rich Salz and Ismo Puustinen <ismo.puustinen@intel.com>] Changes between 1.0.2c and 1.0.2d [9 Jul 2015] |