From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [openssl-announce] OpenSSL Security Advisory Date: Thu, 28 Jan 2016 15:39:16 +0000 Message-ID: <1453995556.585.180.camel@ipfire.org> In-Reply-To: <20160128150547.GA26799@openssl.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3159587064119249922==" List-Id: --===============3159587064119249922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, just wanted to inform you guys that the patches for the latest OpenSSL security vulnerabilities have been published. We have branched a new Core Update with these fixes and are going to release this update for testing later today. Stay tuned. Best, -Michael On Thu, 2016-01-28 at 15:05 +0000, OpenSSL wrote: > OpenSSL Security Advisory [28th Jan 2016] > ========================================= > > NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. > NO > SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME > SECURITY FIXES > ONLY ARE BEING APPLIED. > > DH small subgroups (CVE-2016-0701) > ================================== > > Severity: High > > Historically OpenSSL usually 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. > > OpenSSL before 1.0.2f will reuse the key if: > - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and > SSL_OP_SINGLE_DH_USE is not > set. > - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, > and both the > parameters and the key are set and SSL_OP_SINGLE_DH_USE is not > used. This is > an undocumted feature and parameter files don't contain the key. > - Static DH ciphersuites are used. The key is part of the certificate > and > so it will always reuse it. This is only supported in 1.0.2. > > It will not reuse the key for DHE ciphers suites if: > - SSL_OP_SINGLE_DH_USE is set > - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and > the > callback does not provide the key, only the parameters. The > callback is > almost always used like this. > > Non-safe primes are generated by OpenSSL when using: > - genpkey with the dh_rfc5114 option. This will write an X9.42 style > file > including the prime-order subgroup size "q". This is supported > since the 1.0.2 > version. Older versions can't read files generated in this way. > - dhparam with the -dsaparam option. This has always been documented > as > requiring the single use. > > 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 affects OpenSSL version 1.0.2. > > OpenSSL 1.0.2 users should upgrade to 1.0.2f > > OpenSSL 1.0.1 is not affected by this CVE because it does not support > X9.42 > based parameters. It is possible to generate parameters using non > "safe" primes, > but this option has always been documented as requiring single use > and is not > the default or believed to be common. However, as a precaution, the > SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r. > > This issue was reported to OpenSSL on 12 January 2016 by Antonio > Sanso (Adobe). > The fix was developed by Matt Caswell of the OpenSSL development team > (incorporating some work originally written by Stephen Henson of the > OpenSSL > core team). > > SSLv2 doesn't block disabled ciphers (CVE-2015-3197) > ==================================================== > > Severity: Low > > 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 affects OpenSSL versions 1.0.2 and 1.0.1. > > OpenSSL 1.0.2 users should upgrade to 1.0.2f > OpenSSL 1.0.1 users should upgrade to 1.0.1r > > This issue was reported to OpenSSL on 26th December 2015 by Nimrod > Aviram and > Sebastian Schinzel. The fix was developed by Nimrod Aviram with > further > development by Viktor Dukhovni of the OpenSSL development team. > > > An update on DHE man-in-the-middle protection (Logjam) > ==================================================================== > > A previously published vulnerability in the TLS protocol allows a > man-in-the-middle attacker to downgrade vulnerable TLS connections > using ephemeral Diffie-Hellman key exchange to 512-bit export-grade > cryptography. This vulnerability is known as Logjam > (CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by > rejecting handshakes with DH parameters shorter than 768 bits in > releases 1.0.2b and 1.0.1n. > > This limit has been increased to 1024 bits in this release, to offer > stronger cryptographic assurance for all TLS connections using > ephemeral Diffie-Hellman key exchange. > > OpenSSL 1.0.2 users should upgrade to 1.0.2f > OpenSSL 1.0.1 users should upgrade to 1.0.1r > > The fix was developed by Kurt Roeckx of the OpenSSL development team. > > Note > ==== > > As per our previous announcements and our Release Strategy > (https://www.openssl.org/policies/releasestrat.html), support for > OpenSSL > version 1.0.1 will cease on 31st December 2016. No security updates > for that > version will be provided after that date. Users of 1.0.1 are > advised to upgrade. > > Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. > Those versions > are no longer receiving security updates. > > References > ========== > > URL for this Security Advisory: > https://www.openssl.org/news/secadv/20160128.txt > > Note: the online version of the advisory may be updated with > additional > details over time. > > For details of OpenSSL severity classifications please see: > https://www.openssl.org/policies/secpolicy.html > > _______________________________________________ > openssl-announce mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-announce --===============3159587064119249922== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSldxallrQUFvSkVJQjU4UDl2a0FrSGY3NFAvUndVUzV6M3FuN1BQTTdVdStoQnljV3oK QU91alRjb1R6bTkxaVd3YVI5aXQydlhGQmFoNXJIME51OVREQ3p0Z1lHUVV2YzBOVkhabHFTWC9Q eG1yMWFaSApaTGtKa2E4UnZIcDRKdkNmTVkza09TTnQ1a0pzSGhlQWpGeitPWWNlQzgvT0NIOEhi bW5GeUVxK1ZGNElFM2R2CjUyMTFNZEtpMjQzeDg5NlRlSU9jcVJDUGkxRkJZam9FdSsxMzVnQVlQ b0ExanhQTllWOXJRMi9VcW9idEVaOWYKZmRUY1ZPaHo0VHdST1hzV2hqSkZRako4MzBWanMyQlcw RENZbnM1TXRNaytUQXNzTjRIUWE0dmdsNy9Gc0pXNgpGM2crWjI2cGJJVGRKUkpqZFM0Y203ejUv Ymo3eXJSZWpGYjd4T25RUUZoTmVwQ1MyKytkekwrRlp2SUJlVi9uCllQSmVrWFJPS2l6djNTQmpi VjFOZEptb2lPUk5tdTBzZCtQbmQvY2VTU1V3VTVYNm1EVngzeTIvNTNid2h3TEYKblpxZFhwQ0du WEJtdldUWnJrNzFMNmNSOTNYSWtKQldManhYcmN6VDZpNFdwc21XM3htUjUxcXY5R1B0MEdrNgpK Tm1WMWxSaFc5RDVrUC80NXoreEFGUFptUmhtSnRQMVRnNUxXZXZ5NndkS2w2ZzhvU2t3d3pTZXFp RThqNnNtClZJMjdnSVovQU1zYWpMRkdkNy9KNThlMFFJcHAwRUhkQ1llN3BXMVBzSnRSeTdvS3Ns QTk5N0hXUWhQdWVKQWkKQUtrbHIrbkZNVkJRVmlUbzNlbkhPL2cyZC94Z284UDRPSjI4NU15WXB4 MHRBcFFlVnpqbEpqYzlhbzZROU9XaApIdS9ON0lYM2VtQlNpS0kySE9LbQo9S1RKWAotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============3159587064119249922==--