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, master has been updated via a80d817716406d88b8c7e82397f4618d64e499a9 (commit) via 74a02d3372fe99bfa5dee8bfed6b64670d99775f (commit) from 3ce4d238d255477a240c3b1479cb34828c87fb59 (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 a80d817716406d88b8c7e82397f4618d64e499a9 Author: Michael Tremer michael.tremer@ipfire.org Date: Tue Sep 3 18:02:34 2024 +0000
core188: Ship OpenSSL
Signed-off-by: Michael Tremer michael.tremer@ipfire.org
commit 74a02d3372fe99bfa5dee8bfed6b64670d99775f Author: Michael Tremer michael.tremer@ipfire.org Date: Tue Sep 3 18:00:17 2024 +0000
openssl: Update to 3.3.2
Possible denial of service in X.509 name checks (CVE-2024-6119) ===============================================================
Severity: Moderate
Issue summary: Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address resulting in abnormal termination of the application process.
Impact summary: Abnormal termination of an application can a cause a denial of service.
Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address when comparing the expected name with an `otherName` subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program.
Note that basic certificate chain validation (signatures, dates, ...) is not affected, the denial of service can occur only when the application also specifies an expected DNS name, Email address or IP address.
TLS servers rarely solicit client certificates, and even when they do, they generally don't perform a name check against a "reference identifier" (expected identity), but rather extract the presented identity after checking the certificate chain. So TLS servers are generally not affected and the severity of the issue is Moderate.
The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.1.1 and 1.0.2 are also not affected by this issue.
OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
Signed-off-by: Michael Tremer michael.tremer@ipfire.org
-----------------------------------------------------------------------
Summary of changes: config/rootfiles/{oldcore/100 => core/188}/filelists/openssl | 0 lfs/openssl | 4 ++-- 2 files changed, 2 insertions(+), 2 deletions(-) copy config/rootfiles/{oldcore/100 => core/188}/filelists/openssl (100%)
Difference in files: diff --git a/config/rootfiles/core/188/filelists/openssl b/config/rootfiles/core/188/filelists/openssl new file mode 120000 index 000000000..e011a9266 --- /dev/null +++ b/config/rootfiles/core/188/filelists/openssl @@ -0,0 +1 @@ +../../../common/openssl \ No newline at end of file diff --git a/lfs/openssl b/lfs/openssl index d6333f7a4..22a670118 100644 --- a/lfs/openssl +++ b/lfs/openssl @@ -24,7 +24,7 @@
include Config
-VER = 3.3.1 +VER = 3.3.2
THISAPP = openssl-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -72,7 +72,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_BLAKE2 = b09bbe94f49c33015fbcee5f578a20c0da33c289791bf33292170d5d3de44ea2e22144ee11067947aef2733e979c0fded875a4ec92d81468285837053447e68e +$(DL_FILE)_BLAKE2 = cc53d45418673bc2a406d6697b8bd17ff6c726463c4ccc87bb2fa5a6592d0d178dc8cfeb2fbb980ea354a5dc2c86f31c48453427c6937896c7221273e623c9b5
install : $(TARGET)
hooks/post-receive -- IPFire 2.x development tree