Re: [openssl-announce] OpenSSL Security Advisory

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 6841 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]