The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an inappropriate number, as demonstrated by a number in an X9.42 file.

This update for openssl fixes the following issues :

  - OpenSSL Security Advisory [07 Dec 2017]

  - CVE-2017-3737: OpenSSL 1.0.2 (starting from version     1.0.2b) introduced an \'error state\' mechanism. The     intent was that if a fatal error occurred during a     handshake then OpenSSL would move into the error state     and would immediately fail if you attempted to continue     the handshake. This works as designed for the explicit     handshake functions (SSL_do_handshake(), SSL_accept()     and SSL_connect()), however due to a bug it does not     work correctly if SSL_read() or SSL_write() is called     directly. In that scenario, if the handshake fails then     a fatal error will be returned in the initial function     call. If SSL_read()/SSL_write() is subsequently called     by the application for the same SSL object then it will     succeed and the data is passed without being     decrypted/encrypted directly from the SSL/TLS record     layer. In order to exploit this issue an application bug     would have to be present that resulted in a call to     SSL_read()/SSL_write() being issued after having already     received a fatal error. OpenSSL version 1.0.2b-1.0.2m     are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is     not affected. (bsc#1071905)

  - CVE-2017-3738: There is an overflow bug in the AVX2     Montgomery multiplication procedure used in     exponentiation with 1024-bit moduli. No EC algorithms     are affected. Analysis suggests that attacks against RSA     and DSA as a result of this defect would be very     difficult to perform and are not believed likely.
    Attacks against DH1024 are considered just feasible,     because most of the work necessary to deduce information     about a private key may be performed offline. The amount     of resources required for such an attack would be     significant. However, for an attack on TLS to be     meaningful, the server would have to share the DH1024     private key among multiple clients, which is no longer     an option since CVE-2016-0701. This only affects     processors that support the AVX2 but not ADX extensions     like Intel Haswell (4th generation). Note: The impact     from this issue is similar to CVE-2017-3736,     CVE-2017-3732 and CVE-2015-3193. (bsc#1071906)

Note that Tenable Network Security has extracted the preceding description block directly from the SUSE security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

This update for openssl fixes the following issues :

  - OpenSSL Security Advisory [07 Dec 2017]

  - CVE-2017-3737: OpenSSL 1.0.2 (starting from version     1.0.2b) introduced an \'error state\' mechanism. The     intent was that if a fatal error occurred during a     handshake then OpenSSL would move into the error state     and would immediately fail if you attempted to continue     the handshake. This works as designed for the explicit     handshake functions (SSL_do_handshake(), SSL_accept()     and SSL_connect()), however due to a bug it does not     work correctly if SSL_read() or SSL_write() is called     directly. In that scenario, if the handshake fails then     a fatal error will be returned in the initial function     call. If SSL_read()/SSL_write() is subsequently called     by the application for the same SSL object then it will     succeed and the data is passed without being     decrypted/encrypted directly from the SSL/TLS record     layer. In order to exploit this issue an application bug     would have to be present that resulted in a call to     SSL_read()/SSL_write() being issued after having already     received a fatal error. OpenSSL version 1.0.2b-1.0.2m     are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is     not affected. (bsc#1071905)

  - CVE-2017-3738: There is an overflow bug in the AVX2     Montgomery multiplication procedure used in     exponentiation with 1024-bit moduli. No EC algorithms     are affected. Analysis suggests that attacks against RSA     and DSA as a result of this defect would be very     difficult to perform and are not believed likely.
    Attacks against DH1024 are considered just feasible,     because most of the work necessary to deduce information     about a private key may be performed offline. The amount     of resources required for such an attack would be     significant. However, for an attack on TLS to be     meaningful, the server would have to share the DH1024     private key among multiple clients, which is no longer     an option since CVE-2016-0701. This only affects     processors that support the AVX2 but not ADX extensions     like Intel Haswell (4th generation). Note: The impact     from this issue is similar to CVE-2017-3736,     CVE-2017-3732 and CVE-2015-3193. (bsc#1071906)

This update was imported from the SUSE:SLE-12-SP2:Update update project.

Invoking SSL_read()/SSL_write() while in an error state causes data to be passed without being decrypted/encrypted directly from the SSL/TLS record layer.

In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. [CVE-2017-3737]

There is an overflow bug in the x86_64 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). [CVE-2017-3738] This bug only affects FreeBSD 11.x. Impact : Applications with incorrect error handling may inappropriately pass unencrypted data. [CVE-2017-3737]

Mishandling of carry propagation will produce incorrect output, and make it easier for a remote attacker to obtain sensitive private-key information. No EC algorithms are affected and analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely.

Attacks against DH1024 are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. [CVE-2017-3738]

According to its banner, the version of OpenSSL on the remote host is 1.0.2 prior to 1.0.2f and is affected by a flaw in the 'DH_check_pub_key()' function in 'crypto/dh/dh_check.c' that is triggered when generating DH parameters based on unsafe primes. By completing multiple handshakes with a peer, a remote attacker can potentially disclose the peer's private DH exponent.

New upstream version fixing one high serverity and one low severity security issue.

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote host is affected by the vulnerability described in GLSA-201601-05 (OpenSSL: Multiple vulnerabilities)

    Multiple vulnerabilities have been discovered in OpenSSL. Please review       the upstream advisory and CVE identifiers referenced below for details.
      Note that the list includes CVE identifiers for an older OpenSSL Security       Advisory (3 Dec 2015) for which we have not issued a GLSA before.
  Impact :

    A remote attacker could disclose a server&rsquo;s private DH exponent, or       complete SSLv2 handshakes using ciphers that have been disabled on the       server.
  Workaround :

    There is no known workaround at this time.

The version of OpenSSL installed on the remote host is prior to 1.0.2f. It is, therefore, affected by multiple vulnerabilities as referenced in the 1.0.2f advisory.

  - The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that     prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote     attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an     inappropriate number, as demonstrated by a number in an X9.42 file. (CVE-2016-0701)

  - ssl/s2_srvr.c in OpenSSL 1.0.1 before 1.0.1r and 1.0.2 before 1.0.2f does not prevent use of disabled     ciphers, which makes it easier for man-in-the-middle attackers to defeat cryptographic protection     mechanisms by performing computations on SSLv2 traffic, related to the get_client_master_key and     get_client_hello functions. (CVE-2015-3197)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Antonio Sanso discovered that OpenSSL reused the same private DH exponent for the life of a server process when configured with a X9.42 style parameter file. This could allow a remote attacker to possibly discover the server's private DH exponent when being used with non-safe primes.

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

OpenSSL project reports :

- 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.
(CVE-2016-0701)

- 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. (CVE-2015-3197)

ID	Name	Product	Family	Severity
105353	SUSE SLED12 / SLES12 Security Update : openssl (SUSE-SU-2017:3343-1)	Nessus	SuSE Local Security Checks	medium
105341	openSUSE Security Update : openssl (openSUSE-2017-1381)	Nessus	SuSE Local Security Checks	medium
105141	FreeBSD : FreeBSD -- OpenSSL multiple vulnerabilities (9f7a0f39-ddc0-11e7-b5af-a4badb2f4699)	Nessus	FreeBSD Local Security Checks	medium
9465	OpenSSL 1.0.2 < 1.0.2f Information Disclosure	Nessus Network Monitor	Web Servers	low
89543	Fedora 23 : openssl-1.0.2f-1.fc23 (2016-527018d2ff)	Nessus	Fedora Local Security Checks	medium
88586	GLSA-201601-05 : OpenSSL: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
88530	OpenSSL 1.0.2 < 1.0.2f Multiple Vulnerabilities	Nessus	Web Servers	medium
88487	Ubuntu 15.10 : openssl vulnerability (USN-2883-1)	Nessus	Ubuntu Local Security Checks	low
88465	FreeBSD : openssl -- multiple vulnerabilities (3679fd10-c5d1-11e5-b85f-0018fe623f2b)	Nessus	FreeBSD Local Security Checks	medium

Detections

Analytics

CVE-2016-0701

low

Tenable Plugins

medium

medium

medium

low

medium

high

medium

low

medium