|
2 | 2 | OpenSSL CHANGES |
3 | 3 | _______________ |
4 | 4 |
|
| 5 | + Changes between 1.0.1r and 1.0.1s [1 Mar 2016] |
| 6 | + |
| 7 | + * Disable weak ciphers in SSLv3 and up in default builds of OpenSSL. |
| 8 | + Builds that are not configured with "enable-weak-ssl-ciphers" will not |
| 9 | + provide any "EXPORT" or "LOW" strength ciphers. |
| 10 | + [Viktor Dukhovni] |
| 11 | + |
| 12 | + * Disable SSLv2 default build, default negotiation and weak ciphers. SSLv2 |
| 13 | + is by default disabled at build-time. Builds that are not configured with |
| 14 | + "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, |
| 15 | + users who want to negotiate SSLv2 via the version-flexible SSLv23_method() |
| 16 | + will need to explicitly call either of: |
| 17 | + |
| 18 | + SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); |
| 19 | + or |
| 20 | + SSL_clear_options(ssl, SSL_OP_NO_SSLv2); |
| 21 | + |
| 22 | + as appropriate. Even if either of those is used, or the application |
| 23 | + explicitly uses the version-specific SSLv2_method() or its client and |
| 24 | + server variants, SSLv2 ciphers vulnerable to exhaustive search key |
| 25 | + recovery have been removed. Specifically, the SSLv2 40-bit EXPORT |
| 26 | + ciphers, and SSLv2 56-bit DES are no longer available. |
| 27 | + (CVE-2016-0800) |
| 28 | + [Viktor Dukhovni] |
| 29 | + |
| 30 | + *) Fix a double-free in DSA code |
| 31 | + |
| 32 | + A double free bug was discovered when OpenSSL parses malformed DSA private |
| 33 | + keys and could lead to a DoS attack or memory corruption for applications |
| 34 | + that receive DSA private keys from untrusted sources. This scenario is |
| 35 | + considered rare. |
| 36 | + |
| 37 | + This issue was reported to OpenSSL by Adam Langley(Google/BoringSSL) using |
| 38 | + libFuzzer. |
| 39 | + (CVE-2016-0705) |
| 40 | + [Stephen Henson] |
| 41 | + |
| 42 | + *) Disable SRP fake user seed to address a server memory leak. |
| 43 | + |
| 44 | + Add a new method SRP_VBASE_get1_by_user that handles the seed properly. |
| 45 | + |
| 46 | + SRP_VBASE_get_by_user had inconsistent memory management behaviour. |
| 47 | + In order to fix an unavoidable memory leak, SRP_VBASE_get_by_user |
| 48 | + was changed to ignore the "fake user" SRP seed, even if the seed |
| 49 | + is configured. |
| 50 | + |
| 51 | + Users should use SRP_VBASE_get1_by_user instead. Note that in |
| 52 | + SRP_VBASE_get1_by_user, caller must free the returned value. Note |
| 53 | + also that even though configuring the SRP seed attempts to hide |
| 54 | + invalid usernames by continuing the handshake with fake |
| 55 | + credentials, this behaviour is not constant time and no strong |
| 56 | + guarantees are made that the handshake is indistinguishable from |
| 57 | + that of a valid user. |
| 58 | + (CVE-2016-0798) |
| 59 | + [Emilia Käsper] |
| 60 | + |
| 61 | + *) Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption |
| 62 | + |
| 63 | + In the BN_hex2bn function the number of hex digits is calculated using an |
| 64 | + int value |i|. Later |bn_expand| is called with a value of |i * 4|. For |
| 65 | + large values of |i| this can result in |bn_expand| not allocating any |
| 66 | + memory because |i * 4| is negative. This can leave the internal BIGNUM data |
| 67 | + field as NULL leading to a subsequent NULL ptr deref. For very large values |
| 68 | + of |i|, the calculation |i * 4| could be a positive value smaller than |i|. |
| 69 | + In this case memory is allocated to the internal BIGNUM data field, but it |
| 70 | + is insufficiently sized leading to heap corruption. A similar issue exists |
| 71 | + in BN_dec2bn. This could have security consequences if BN_hex2bn/BN_dec2bn |
| 72 | + is ever called by user applications with very large untrusted hex/dec data. |
| 73 | + This is anticipated to be a rare occurrence. |
| 74 | + |
| 75 | + All OpenSSL internal usage of these functions use data that is not expected |
| 76 | + to be untrusted, e.g. config file data or application command line |
| 77 | + arguments. If user developed applications generate config file data based |
| 78 | + on untrusted data then it is possible that this could also lead to security |
| 79 | + consequences. This is also anticipated to be rare. |
| 80 | + |
| 81 | + This issue was reported to OpenSSL by Guido Vranken. |
| 82 | + (CVE-2016-0797) |
| 83 | + [Matt Caswell] |
| 84 | + |
| 85 | + *) Fix memory issues in BIO_*printf functions |
| 86 | + |
| 87 | + The internal |fmtstr| function used in processing a "%s" format string in |
| 88 | + the BIO_*printf functions could overflow while calculating the length of a |
| 89 | + string and cause an OOB read when printing very long strings. |
| 90 | + |
| 91 | + Additionally the internal |doapr_outch| function can attempt to write to an |
| 92 | + OOB memory location (at an offset from the NULL pointer) in the event of a |
| 93 | + memory allocation failure. In 1.0.2 and below this could be caused where |
| 94 | + the size of a buffer to be allocated is greater than INT_MAX. E.g. this |
| 95 | + could be in processing a very long "%s" format string. Memory leaks can |
| 96 | + also occur. |
| 97 | + |
| 98 | + The first issue may mask the second issue dependent on compiler behaviour. |
| 99 | + These problems could enable attacks where large amounts of untrusted data |
| 100 | + is passed to the BIO_*printf functions. If applications use these functions |
| 101 | + in this way then they could be vulnerable. OpenSSL itself uses these |
| 102 | + functions when printing out human-readable dumps of ASN.1 data. Therefore |
| 103 | + applications that print this data could be vulnerable if the data is from |
| 104 | + untrusted sources. OpenSSL command line applications could also be |
| 105 | + vulnerable where they print out ASN.1 data, or if untrusted data is passed |
| 106 | + as command line arguments. |
| 107 | + |
| 108 | + Libssl is not considered directly vulnerable. Additionally certificates etc |
| 109 | + received via remote connections via libssl are also unlikely to be able to |
| 110 | + trigger these issues because of message size limits enforced within libssl. |
| 111 | + |
| 112 | + This issue was reported to OpenSSL Guido Vranken. |
| 113 | + (CVE-2016-0799) |
| 114 | + [Matt Caswell] |
| 115 | + |
| 116 | + *) Side channel attack on modular exponentiation |
| 117 | + |
| 118 | + A side-channel attack was found which makes use of cache-bank conflicts on |
| 119 | + the Intel Sandy-Bridge microarchitecture which could lead to the recovery |
| 120 | + of RSA keys. The ability to exploit this issue is limited as it relies on |
| 121 | + an attacker who has control of code in a thread running on the same |
| 122 | + hyper-threaded core as the victim thread which is performing decryptions. |
| 123 | + |
| 124 | + This issue was reported to OpenSSL by Yuval Yarom, The University of |
| 125 | + Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and |
| 126 | + Nadia Heninger, University of Pennsylvania with more information at |
| 127 | + http://cachebleed.info. |
| 128 | + (CVE-2016-0702) |
| 129 | + [Andy Polyakov] |
| 130 | + |
| 131 | + *) Change the req app to generate a 2048-bit RSA/DSA key by default, |
| 132 | + if no keysize is specified with default_bits. This fixes an |
| 133 | + omission in an earlier change that changed all RSA/DSA key generation |
| 134 | + apps to use 2048 bits by default. |
| 135 | + [Emilia Käsper] |
| 136 | + |
5 | 137 | Changes between 1.0.1q and 1.0.1r [28 Jan 2016] |
6 | 138 |
|
7 | 139 | *) Protection for DH small subgroup attacks |
|
62 | 194 | [Emilia Käsper] |
63 | 195 |
|
64 | 196 | *) In DSA_generate_parameters_ex, if the provided seed is too short, |
65 | | - return an error |
| 197 | + use a random seed, as already documented. |
66 | 198 | [Rich Salz and Ismo Puustinen <ismo.puustinen@intel.com>] |
67 | 199 |
|
68 | 200 | Changes between 1.0.1o and 1.0.1p [9 Jul 2015] |
|
0 commit comments