This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "IPFire 2.x development tree".

The branch, next has been updated via 51d1e9ce4d7f2305bc7cc868a48810a6ef268f4d (commit) from db9f57143f43c863b28ec3f838a1cbf7e8f844e3 (commit)

Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below.

- Log ----------------------------------------------------------------- commit 51d1e9ce4d7f2305bc7cc868a48810a6ef268f4d Author: Michael Tremer michael.tremer@ipfire.org Date: Fri Dec 8 13:58:26 2017 +0000

openssl: Update to 1.0.2n

OpenSSL Security Advisory [07 Dec 2017] ========================================

Read/write after SSL object in error state (CVE-2017-3737) ==========================================================

Severity: Moderate

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.

This issue does not affect OpenSSL 1.1.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 10th November 2017 by David Benjamin (Google). The fix was proposed by David Benjamin and implemented by Matt Caswell of the OpenSSL development team.

rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738) =========================================================

Severity: Low

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.

Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin (Google). The issue was originally found via the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team.

Note ====

Support for version 1.0.1 ended on 31st December 2016. 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/20171207.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

Signed-off-by: Michael Tremer michael.tremer@ipfire.org

-----------------------------------------------------------------------

Summary of changes: .../rootfiles/{oldcore/100 => core/117}/filelists/i586/openssl-sse2 | 0 config/rootfiles/{oldcore/100 => core/117}/filelists/openssl | 0 lfs/openssl | 4 ++-- 3 files changed, 2 insertions(+), 2 deletions(-) copy config/rootfiles/{oldcore/100 => core/117}/filelists/i586/openssl-sse2 (100%) copy config/rootfiles/{oldcore/100 => core/117}/filelists/openssl (100%)

Difference in files: diff --git a/config/rootfiles/core/117/filelists/i586/openssl-sse2 b/config/rootfiles/core/117/filelists/i586/openssl-sse2 new file mode 120000 index 000000000..f424713d6 --- /dev/null +++ b/config/rootfiles/core/117/filelists/i586/openssl-sse2 @@ -0,0 +1 @@ +../../../../common/i586/openssl-sse2 \ No newline at end of file diff --git a/config/rootfiles/core/117/filelists/openssl b/config/rootfiles/core/117/filelists/openssl new file mode 120000 index 000000000..e011a9266 --- /dev/null +++ b/config/rootfiles/core/117/filelists/openssl @@ -0,0 +1 @@ +../../../common/openssl \ No newline at end of file diff --git a/lfs/openssl b/lfs/openssl index 8782e1e05..6050768ec 100644 --- a/lfs/openssl +++ b/lfs/openssl @@ -24,7 +24,7 @@

include Config

-VER = 1.0.2m +VER = 1.0.2n

THISAPP = openssl-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -94,7 +94,7 @@ objects = $(DL_FILE)

$(DL_FILE) = $(DL_FROM)/$(DL_FILE)

-$(DL_FILE)_MD5 = 10e9e37f492094b9ef296f68f24a7666 +$(DL_FILE)_MD5 = 13bdc1b1d1ff39b6fd42a255e74676a4

install : $(TARGET)

hooks/post-receive -- IPFire 2.x development tree