"The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 3.0.7. This release will be made available on Tuesday 1st November 2022 between 1300-1700 UTC. OpenSSL 3.0.7 is a security-fix release. The highest severity issue fixed in this release is CRITICAL: https://www.openssl.org/policies/general/security-policy.html" Seems to only affect openssl-3, so impact is minimal for us: https://twitter.com/__agwa/status/1584916999947313152
The "URL" field does not seem to be correct. It should be https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html.
(In reply to Tee KOBAYASHI from comment #1) > The "URL" field does not seem to be correct. It should be > https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html. Thanks! Sorry about that.
Upstream tarball is live: https://www.openssl.org/source/openssl-3.0.7.tar.gz
From the changelog: ### Changes between 3.0.6 and 3.0.7 [1 Nov 2022] * Fixed two buffer overflows in punycode decoding functions. A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. An attacker can craft a malicious email address to overflow an arbitrary number of bytes containing the `.` character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). ([CVE-2022-3786]) An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution depending on stack layout for any given platform/compiler. ([CVE-2022-3602])
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c40f1c782a71d48b194236040145c171190a25f commit 4c40f1c782a71d48b194236040145c171190a25f Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2022-11-01 15:47:50 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2022-11-01 15:48:02 +0000 dev-libs/openssl: security bump Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Bug: https://bugs.gentoo.org/878269 dev-libs/openssl/Manifest | 2 + dev-libs/openssl/openssl-3.0.7.ebuild | 337 ++++++++++++++++++++++++++++++++++ 2 files changed, 339 insertions(+)
Please cleanup remaining vulnerable 3.x ebuilds.
Advisory at URL.
GLSA request filed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e07628f6e8bffb7e8f154e6610e0f5d0393a901f commit e07628f6e8bffb7e8f154e6610e0f5d0393a901f Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-11-01 21:02:08 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-11-01 21:12:15 +0000 dev-libs/libxml2: drop 2.10.2 Bug: https://bugs.gentoo.org/877149 Bug: https://bugs.gentoo.org/878269 Signed-off-by: John Helmert III <ajak@gentoo.org> dev-libs/libxml2/Manifest | 1 - dev-libs/libxml2/libxml2-2.10.2.ebuild | 194 --------------------------------- 2 files changed, 195 deletions(-)
(In reply to Larry the Git Cow from comment #9) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=e07628f6e8bffb7e8f154e6610e0f5d0393a901f > > commit e07628f6e8bffb7e8f154e6610e0f5d0393a901f > Author: John Helmert III <ajak@gentoo.org> > AuthorDate: 2022-11-01 21:02:08 +0000 > Commit: John Helmert III <ajak@gentoo.org> > CommitDate: 2022-11-01 21:12:15 +0000 > > dev-libs/libxml2: drop 2.10.2 > > Bug: https://bugs.gentoo.org/877149 > Bug: https://bugs.gentoo.org/878269 > Signed-off-by: John Helmert III <ajak@gentoo.org> > > dev-libs/libxml2/Manifest | 1 - > dev-libs/libxml2/libxml2-2.10.2.ebuild | 194 > --------------------------------- > 2 files changed, 195 deletions(-) Sorry, did not mean to tag this bug.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=273d516e3c9a0078775979649ecc570e7186f050 commit 273d516e3c9a0078775979649ecc570e7186f050 Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2022-11-01 21:56:08 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-11-01 21:58:53 +0000 [ GLSA 202211-01 ] OpenSSL: Multiple Vulnerabilities Bug: https://bugs.gentoo.org/878269 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: John Helmert III <ajak@gentoo.org> glsa-202211-01.xml | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+)
Whoops, GLSA is released. All done!
Could you consider cleaning up the GLSA to be correct in that vulnerable versions are >3.0 and <3.0.7? OpenSSL 1.1.1q - current stable in portage for amd64 and x86 - is not exposed to this vulnerability. This GLSA will almost certainly cause external security scanning vendors (such as Nessus) to force an upgrade to openssl 3.7 to remain compliant. Not to mention being forced to rebuild attendant packages that are compiled against openssl. This is unnecessary for folks who are not using OpenSSL 3.x.
(In reply to cmwatts from comment #13) > Could you consider cleaning up the GLSA to be correct in that vulnerable > versions are >3.0 and <3.0.7? > > OpenSSL 1.1.1q - current stable in portage for amd64 and x86 - is not > exposed to this vulnerability. > > This GLSA will almost certainly cause external security scanning vendors > (such as Nessus) to force an upgrade to openssl 3.7 to remain compliant. Not > to mention being forced to rebuild attendant packages that are compiled > against openssl. This is unnecessary for folks who are not using OpenSSL 3.x. But it is correct? https://security.gentoo.org/glsa/202211-01 has misleading text, but the XML has a subslot in its affected versions. https://gitweb.gentoo.org/data/glsa.git/commit/?id=273d516e3c9a0078775979649ecc570e7186f050 We need to make the website handle displaying slots.
The issue is that vendors (like Tenable) will just read the GLSA and create plugins for vulnerability scanning based on what has been published. In that case, that is that any version of OpenSSL <3.0.7 is a 'vulnerability'. So, getting the vulnerable versions published so that they match the exposure is actually important from that perspective.
(In reply to cmwatts from comment #15) > The issue is that vendors (like Tenable) will just read the GLSA and create > plugins for vulnerability scanning based on what has been published. In that > case, that is that any version of OpenSSL <3.0.7 is a 'vulnerability'. So, > getting the vulnerable versions published so that they match the exposure is > actually important from that perspective. We can fix the website (I'm on it) to include (sub)slots, but I can't ensure that Tenable would then parse it correctly. The only way to get the unaffected range correct is to use subslots right now.
(In reply to cmwatts from comment #15) > The issue is that vendors (like Tenable) will just read the GLSA and create > plugins for vulnerability scanning based on what has been published. In that > case, that is that any version of OpenSSL <3.0.7 is a 'vulnerability'. So, > getting the vulnerable versions published so that they match the exposure is > actually important from that perspective. I'm not sure this bug is the best place to discuss this. Please open a new bug with a description of what you're seeking that we change.
Thanks, have opened https://bugs.gentoo.org/880521 as a separate bug to ask about this behavior as a possible enhancement request.
