openssl-1.0.2f

[Fernando de Oliveira]

This is a Secutity Release

CVE-2016-0701 CVE-2015-3197 CVE-2015-4000 (Logjam - 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

​https://www.openssl.org/source/openssl-1.0.2f.tar.gz

​https://www.openssl.org/source/openssl-1.0.2f.tar.gz.asc

​https://www.openssl.org/source/openssl-1.0.1q.tar.gz.sha1

c65a7bec49b72092d7ebb97a263c496cc1e1d6af

Downloads:

​https://www.openssl.org/source/

Vulnerabilities

​https://www.openssl.org/news/secadv/20160128.txt

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

Changelog:

​https://www.openssl.org/news/cl102.txt

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]

[Fernando de Oliveira]

Fixed at r16865.