Icinga 2 is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. Prior to versions 2.12.12, 2.13.12, and 2.14.6, the VerifyCertificate() function can be tricked into incorrectly treating certificates as valid. This allows an attacker to send a malicious certificate request that is then treated as a renewal of an already existing certificate, resulting in the attacker obtaining a valid certificate that can be used to impersonate trusted nodes. This only occurs when Icinga 2 is built with OpenSSL older than version 1.1.0. This issue has been patched in versions 2.12.12, 2.13.12, and 2.14.6.

Summary When verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present any valid cert for a completely different domain they own, and JRuby wouldn't complain.

Details n/a

PoC An example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with certificate verify failed (hostname mismatch), but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3

ruby require "net/http" require "openssl"

uri = URI("https://bad.substitutealert.com/") https = Net::HTTP.new(uri.host, uri.port) https.usessl = true https.verifymode = OpenSSL::SSL::VERIFYPEER

body = https.start { https.get(uri.requesturi).body } puts body

Impact Anybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely

NVIDIA NvContainer service for Windows contains a vulnerability in its usage of OpenSSL, where an attacker could exploit a hard-coded constant issue by copying a malicious DLL in a hard-coded path. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, or data tampering.

I assume a minor typo in the official advisory: OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2. should upgrade to OpenSSL 3.3.3.

Could you fix it on https://openssl-library.org/news/secadv/20250211.txt?

Thanks!

Weak encryption algorithm in Easy-RSA version 3.0.5 through 3.1.7 allows a local attacker to more easily bruteforce the private CA key when created using OpenSSL 3

Am 23.10.24 um 11:10 schrieb Dr. Christopher Kunz:

FWIW,

That explains the different scores.

Best regards,

--cku

Am 16.10.24 um 19:08 schrieb Tomas Mraz: OpenSSL Security Advisory [16th October 2024] =============================================

Low-level invalid GF(2^m) parameters lead to OOB memory access (CVE-2024-9143) ==============================================================================

Severity: Low Good morning everyone,

Thanks,

--cku

Robert Merget, Marcus Brinkmann, Nimrod Aviram, and Juraj Somorovsky discovered that certain Diffie-Hellman ciphersuites in the TLS specification and implemented by OpenSSL contained a flaw. A remote attacker could possibly use this issue to eavesdrop on encrypted communications. This was fixed in this update by removing the insecure ciphersuites from OpenSSL. (CVE-2020-1968) Paul Kehrer discovered that OpenSSL incorrectly handled certain input lengths in EVP functions. A remote attacker could possibly use this issue to cause OpenSSL to crash, resulting in a denial of service. (CVE-2021-23840) Elison Niven discovered that OpenSSL incorrectly handled the crehash script. A local attacker could possibly use this issue to execute arbitrary commands when crehash is run. (CVE-2022-1292) Chancen and Daniel Fiala discovered that OpenSSL incorrectly handled the crehash script. A local attacker could possibly use this issue to execute arbitrary commands when crehash is run. (CVE-2022-2068) It was discovered that OpenSSL incorrectly handled excessively large Diffie-Hellman parameters. An attacker could possibly use this issue to cause a denial of service. (CVE-2023-3446) Bahaa Naamneh discovered that OpenSSL incorrectly handled certain malformed PKCS12 files. A remote attacker could possibly use this issue to cause OpenSSL to crash, resulting in a denial of service. (CVE-2024-0727)

An issue was discovered in Fort before 1.6.3. A malicious RPKI repository that descends from a (trusted) Trust Anchor can serve (via rsync or RRDP) a resource certificate containing a bit string that doesn't properly decode into a Subject Public Key. OpenSSL does not report this problem during parsing, and when compiled with OpenSSL libcrypto versions below 3, Fort recklessly dereferences the pointer. Because Fort is an RPKI Relying Party, a crash can lead to Route Origin Validation unavailability, which can lead to compromised routing.

Hello,

I have no particular insight on the prevalence of TLS 1.0/1.1 these days, but I want to make a more general comment. My impression of OpenSSL is that it has a strong tendency to ship "bloat", i.e., features that either barely anyone needs, but that still get added (remember Heartbeat extension?), or that should've been deprecated long ago.

If this effort to deprecate old protocols is a sign that this is changing, I welcome this. I'd recommend to have a look at other things in the OpenSSL codebase that should be trimmed.

A few examples:

OpenSSL recently had a vuln in the NPN code (CVE-2024-5535). NPN was a mechanism introduced to select an underlying protocol in order to introduce SPDY (later HTTP/2) as an alternative to HTTP/1.1. NPN was replaced by a different mechanism called ALPN. This happened a decade ago (ALPN RFC is from 2014), which leads to the question: Why does OpenSSL still support NPN? It allears like something that can be removed with little or no compatibility risk.

OpenSSL contains code for SCSV, which was an anti-downgrade protection in times where browsers still did out-of-protocol insecure downgrade. I think it was introduced after the POODLE attack. Browsers have long deprecated out-of-protocol downgrades, downgrade protection in TLS 1.3 works entirely different, and with the deprecation of TLS 1.0/1.1, SCSV appears pointless. Again, I don't thinkt here's any big compatibility risk in removal.

OpenSSL contains code for the TLS padding extension, I believe it's even enabled by default. This was introduced due to defect F5 devices that had trouble with TLS handshakes in a certain size range (if my memory is correct, it didn't like anything between 256 and 512 bytes). This was 2013. I hope noone is running such load balancers without firmware updates any more (I somehow doubt they even speak to modern TLS stacks). Again: Candidate for safe removal?

I also think OpenSSL could be more adverse to implementing new features. While 3.3 mainly seems to add QUIC support (I know there's some controversy how OpenSSL does this, but I'm not deep enough into it to comment on it), but I remember that the 3.2 release appeared to me as adding a whole bunch of algorithms that I find at least partly questionable. https://openssl-library.org/news/openssl-3.2-notes/index.html While things like deterministic ECDSA, or Argo2, appear somewhat legit, adding ciphers that are essentially "not invented here syndrome", like Brainpool curves, or SM4, should be avoided. I also think there's probably potential to remove some obsolete ciphers (DSA?).

-- Hanno Böck - Independent security researcher https://itsec.hboeck.de/ https://badkeys.info/

OpenSSL is an important and security-critical piece of software; it's important that it be maintainable, analysable for security properties, and that at runtime people don't have to worry about weird old code paths leading to breaches or instability.

Keeping these old code paths around (and particularly enabled) in "relative perpetuity" is bad for OpenSSL and bad for its users because it prioritises the long tail (that presumably see very little legitimate use nowadays) over the main use; there needs to be some kind of cut-off and acceptance that even if a few historical relics are cut off, it's better for the mainstream. There are other things that will make those legacies harder to use anyhow - cert chains, IPv6, potentially physical connectivity. Given the weights of the interests involved, it's not that hard to peel the relic cases from the it-works-automatically status into the you-may-need-to-take-extra-steps status.

The Linux kernel removes support for old architectures for similar reasons.

If someone were to argue a metric apart from relative perpituity, that'd be different, but I think any reasonable metrics of that flavour would have lines that have already been crossed in terms of usage numbers or any other measurable.

On Wed, 14 Aug 2024 at 07:37, Mike O'Connor <mjo () dojo mi org> wrote: :OpenSSL is currently considering the deprecation of the TLS 1.0/1.1 :protocols. Currently TLS1.1 and TLS 1.0 are disabled at run time, and :requires enablement by reducing the ssl security level value. : :The current proposal under consideration is to explicitly disable TLS :1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release :in the next 12-18 months), with an eye to completely remove the impacted :code in a future major release. The default configuration could be :overridden to re-enable TLS 1.0/1.1 at build time. : :Questions to the community are: : :1) Are distributions/users comfortable with this approach in the time frame :proposed?

Not really. Entities who control the OpenSSL they run on their systems, OSes, etc. don't necessarily control all the broken things that said systems/OSes need to interact with.

:2) Would builders of OpenSSL consider using the default configuration (with :TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols :re-enabled in their builds?

Either it'd be re-enabled in the build, or there'll be a fork that supports TLS 1.0/1.1 in relative perpetuity. It was only recently that some mainstream Linuxes stopped shipping a compat openssl 0.9.8 and all the stale protocol baggage that goes along with that, for support of some "business critical" commercial apps.

:3) If the deprecated protocols are re-enabled, what would constitute a :reasonable warning mechanism to inform users that these protocols are going :away at some point in the future to pressure users to update to a newer, :more secure protocol?

I'd be inclined to position such a move and associated warning message in terms of PQC, which AFAIK doesn't and won't support TLS 1.0/1.1. As PQC gets "refined", it wouldn't surprise me to see the quantum computing boogeyman drive out TLS 1.0/1.1 in critical applications. Let PQC be the spike that kills TLS 1.0/1.1 dead.

I've been leery to post this for fear of going too far down some "quantum" rat's nest. So please, be gentle.

Take FWIW... -Mike

-- Michael J. O'Connor mjo () dojo mi org

=--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "You can't teach an old dogma new tricks." -Dorothy Parker

On 8/8/24 12:46 PM, Clemens Lang wrote: Hi,

Speaking of LTS distros: RHEL 6.10 supports TLS 1.2.

https://access.redhat.com/support/policy/updates/errata/#LifeCycleDates At what point is a distro not LTS, but a museum piece which we can ignore? What currently supported LTS distro does not support TLS 1.2? 2. Scanning or crawling a wide variety of systems, e.g. by a search engine indexer, an asset enumeration tool, a security scanner, or during a pentest. What good is a search engine index of a webpage no modern browser will connect to?

The other use cases sound like they’d be done with special tooling anyway, in which case that can continue to ship an older version of OpenSSL for this purpose. Regards,

Jens Timmerman

Clemens Lang wrote: On 7. Aug 2024, at 19:48, Solar Designer <solar () openwall com> wrote:

1. Hosting a public server that's meant to be usable by the widest audience possible, including from both up-to-date and older systems. For example, a website should display in latest web browsers, but command-line downloads from the same server should also work from old systems (e.g., running LTS distros). Speaking of LTS distros: RHEL 6.10 supports TLS 1.2. At what point is a distro not LTS, but a museum piece which we can ignore? What currently supported LTS distro does not support TLS 1.2?

2. Scanning or crawling a wide variety of systems, e.g. by a search engine indexer, an asset enumeration tool, a security scanner, or during a pentest. What good is a search engine index of a webpage no modern browser will connect to?

The other use cases sound like they’d be done with special tooling anyway, in which case that can continue to ship an older version of OpenSSL for this purpose.

-- Jacob

Steffen Nurpmeso wrote in <20240808190532.Uwg8Ylc@steffen%sdaoden.eu>: |Clemens Lang wrote in | <E3810E68-25CC-456F-9DC4-A03752C43E79 () redhat com>: ||> On 7. Aug 2024, at 22:16, Steffen Nurpmeso <steffen () sdaoden eu> wrote: ... ||> To reiterate that SSL/TLS are standards, they had version ||> iterations, which possibly got around some real protocol problem. ||> These offer standardized sets of ciphersuites, some of those, of ||> the elder versions, are "no longer secure". (I am no ... ||> as i understand it, even TLSv1 supported forward-secrecy stuff, ie ||> ||> # openssl ciphers -v EECDH+AESGCM:EECDH+AES256:CHACHA20:!DHE ||> ||> gives two members, and except for the SHA-1 MAC this looks pretty ||> modern. But again: i am far from being an expert. || ||TLS < 1.2 only supports a single signature algorithm, which uses SHA1-MD5 \ ||\ ||as digest. ||Only TLS >= 1.2 supports the signaturealgorithms extension to negotiate \ ||modern digests. || ||MD-5 is fully broken. SHA-1 is questionable. Their combination may \ ||withstand attacks a little bit longer, but probably not by much. || ||The MAC is actually fine, since it’s HMAC with SHA-1, which isn’t as \ ||affected by a SHA-1 collision attack [1]. || || [1]: https://security.stackexchange.com/questions/187866/why-aren-t-coll\ || \ || isions-important-with-hmac | |Ok, here you got me. I would have to (actually a little bit of |re-) read the entire TLS specification 1.1 (2246) in order to give |some useful answer. Ie, whether the non-HMAC usage of MD5/SHA-1 |in TLSv1.1 is used in a way that is truly problematic, or whether |they exist in data blocks that are protected by other means, |protected by the stream cipher or signed by a key that anyway has |to be verified via private/public key cryptography.

That is: whether "vulnerability" thus means to create a fake packet with identical MD-5 and SHA-1 hashes (it seems TLSv1.1 always uses both concurrently, at least for RSA) as the cryptographically verifiable one that ships with the packet.

It seems to me this is hard stuff, especially for "the occasional attack". But, if the protocol is resistant against downgrading it would be used only for those connections which cannot use anything else.

The real question for me (who cannot help possible remote stations that cannot do any better) is how applications can deal with being specific. For example openssl-sclient(1) allows per-connection cipher suite configuration, the MUA i maintain does so per destination server if you want to, for example. The postfix MTA supports policy maps for at least the client side like this

/etc/postfix/tlspolicy: example.edu none example.mil may example.gov encrypt protocols=TLSv1 example.com verify ciphers=high

This narrows the necessary case of less modern support down to (possibly falsely announced) host names, or fixed IP numbers.

I, as a non-cryptographer, would wonder whether some of the cipher suites that are by default possible do not impose greater risks than that.

|I never read 5246, just downloaded it an hour ago to read the |referenced appendix. (Not a network expert etc.)

Clemens Lang wrote in <E3810E68-25CC-456F-9DC4-A03752C43E79 () redhat com>: |Hello Steffen,

Hallo. (I presume.)

|> On 7. Aug 2024, at 22:16, Steffen Nurpmeso <steffen () sdaoden eu> wrote: |> |> Isn't that terribly rhetorical, and can kill sheeps indeed. |> To reiterate that SSL/TLS are standards, they had version |> iterations, which possibly got around some real protocol problem. |> These offer standardized sets of ciphersuites, some of those, of |> the elder versions, are "no longer secure". (I am no |> cryptographer to tell whether they ever were completely so, or |> whether there are "mathematical tricks" to get away without brute |> force for them. That aside.) That is basically it. But, as far |> as i understand it, even TLSv1 supported forward-secrecy stuff, ie |> |> # openssl ciphers -v EECDH+AESGCM:EECDH+AES256:CHACHA20:!DHE |> |> gives two members, and except for the SHA-1 MAC this looks pretty |> modern. But again: i am far from being an expert. | |TLS < 1.2 only supports a single signature algorithm, which uses SHA1-MD5 \ |as digest. |Only TLS >= 1.2 supports the signaturealgorithms extension to negotiate \ |modern digests. | |MD-5 is fully broken. SHA-1 is questionable. Their combination may \ |withstand attacks a little bit longer, but probably not by much. | |The MAC is actually fine, since it’s HMAC with SHA-1, which isn’t as \ |affected by a SHA-1 collision attack [1]. | | [1]: https://security.stackexchange.com/questions/187866/why-aren-t-coll\ | isions-important-with-hmac

Ok, here you got me. I would have to (actually a little bit of re-) read the entire TLS specification 1.1 (2246) in order to give some useful answer. Ie, whether the non-HMAC usage of MD5/SHA-1 in TLSv1.1 is used in a way that is truly problematic, or whether they exist in data blocks that are protected by other means, protected by the stream cipher or signed by a key that anyway has to be verified via private/public key cryptography. I never read 5246, just downloaded it an hour ago to read the referenced appendix. (Not a network expert etc.)

--steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only during dog days: | On the 81st anniversary of the Goebbel's Sportpalast speech | von der Leyen gave an overlong hypocritical inauguration one. | The brew's essence of our civilizing advancement seems o be: | Total war - shortest war -> Permanent war - everlasting war

On Tue, 2024-08-06 at 05:02 -0400, Neil Horman wrote: The current proposal under consideration is to explicitly disable TLS 1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release in the next 12-18 months), with an eye to completely remove the impacted code in a future major release.  The default configuration could be overridden to re-enable TLS 1.0/1.1 at build time.

Questions to the community are:

1) Are distributions/users comfortable with this approach in the time frame proposed? I lead a quite unusual application (BMC Discovery), which is an IT discovery tool. Its purpose is to connect to everything it can in an IT environment and interrogate it, to find out what it is, and what it is doing.

We would all agree that everything ought to be using modern TLS versions and encryption algorithms, but the reality is that we encounter many ancient systems that are using old protocols. It is important to us that we can connect to things even if they are now considered insecure, not least because that way we can report that they are old and insecure.

Obviously this is quite an unusual use of OpenSSL, but I think it is a good use case for retaining these old algorithms for as long as possible, even if they are disabled by default. If new OpenSSL versions drop support for older protocols, we will have to start using multiple versions, so we can use old OpenSSL versions for old discovery targets.

Regards,

Duncan Grisby.

-- Duncan Grisby <duncan () grisby org>

Ack, thank you for the candid feedback, it's helpful

On Tue, Aug 6, 2024, 6:10 PM Alex Gaynor <alex.gaynor () gmail com> wrote: Hi Neil,

Answering on behalf of the Python Cryptographic Authority, which develops pyca/cryptography, the most widely used Python cryptography library. We distribute binary builds that statically link a copy of OpenSSL.

1) Yes, we're fine with dropping TLS 1.0/1.1 on this time frame. Frankly, we'd be fine dropping it faster.

2) We would not re-enable TLS1.0/1.1 in our releases. Users wishing to use these protocols would be responsible for building and linking their own OpenSSL.

3) I don't have a good answer for you. I think systems programming is fairly impoverished in terms of ways to emit runtime warnings. I'd suggest focusing on compile-time warnings.

Alex

On Tue, Aug 6, 2024 at 7:29 AM Neil Horman <nhorman () openssl org> wrote: Neil Horman <nhorman () openssl org> 4:19 AM (42 minutes ago) to openssl-security

OpenSSL is currently considering the deprecation of the TLS 1.0/1.1 protocols. Currently TLS1.1 and TLS 1.0 are disabled at run time, and requires enablement by reducing the ssl security level value.

The current proposal under consideration is to explicitly disable TLS 1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release in the next 12-18 months), with an eye to completely remove the impacted code in a future major release. The default configuration could be overridden to re-enable TLS 1.0/1.1 at build time.

Questions to the community are:

1) Are distributions/users comfortable with this approach in the time frame proposed?

2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds?

3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol?

Input on these questions is requested and appreciated -- All that is necessary for evil to succeed is for good people to do nothing.

Hi Neil,

Answering on behalf of the Python Cryptographic Authority, which develops pyca/cryptography, the most widely used Python cryptography library. We distribute binary builds that statically link a copy of OpenSSL.

1) Yes, we're fine with dropping TLS 1.0/1.1 on this time frame. Frankly, we'd be fine dropping it faster.

2) We would not re-enable TLS1.0/1.1 in our releases. Users wishing to use these protocols would be responsible for building and linking their own OpenSSL.

3) I don't have a good answer for you. I think systems programming is fairly impoverished in terms of ways to emit runtime warnings. I'd suggest focusing on compile-time warnings.

Alex

On Tue, Aug 6, 2024 at 7:29 AM Neil Horman <nhorman () openssl org> wrote: Neil Horman <nhorman () openssl org> 4:19 AM (42 minutes ago) to openssl-security

OpenSSL is currently considering the deprecation of the TLS 1.0/1.1 protocols. Currently TLS1.1 and TLS 1.0 are disabled at run time, and requires enablement by reducing the ssl security level value.

The current proposal under consideration is to explicitly disable TLS 1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release in the next 12-18 months), with an eye to completely remove the impacted code in a future major release. The default configuration could be overridden to re-enable TLS 1.0/1.1 at build time.

Questions to the community are:

1) Are distributions/users comfortable with this approach in the time frame proposed?

2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds?

3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol?

Input on these questions is requested and appreciated -- All that is necessary for evil to succeed is for good people to do nothing.

Hi Neil, On 6. Aug 2024, at 11:02, Neil Horman <nhorman () openssl org> wrote:

1) Are distributions/users comfortable with this approach in the time frame proposed? I don’t think this will be a problem for Fedora, CentOS Stream, and RHEL. They mostly disable TLS <1.2 without a simple way to bring it back already. 2) Would builders of OpenSSL consider using the default configuration (with TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols re-enabled in their builds? I would strongly argue for keeping those disabled in Fedora. It’s already not simple to re-enabled them in CentOS Stream or RHEL. 3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol? I believe the best you can do as a library is what you are already doing: Disabling by default, and possibly marking any TLS-1.0/1.1-specific APIs deprecated.

Logging to stderr from a library is out of the question. Logging to syslog can fail due to SELinux on distros that have it.

The only other good solution we’ve come up with is to add a USDT probe point to deprecated code paths and provide a utility for users to run on their system that will highlight any use of these code paths. That’s Linux-specific, and most users won’t run such a tool, though.

HTH, Clemens

-- Clemens Lang RHEL Crypto Team Red Hat

On 2024/08/06 17:12, Marco Moock wrote: Am Tue, 6 Aug 2024 05:02:14 -0400 schrieb Neil Horman <nhorman () openssl org>: 1) Are distributions/users comfortable with this approach in the time frame proposed? As a user, this is acceptable for me, but I know there are still machines outside that only offer such old versions. Some of them can't be upgraded easily because the vendor doesn't provide any new versions. BTW, mainstream web browsers disabled pre-1.2 TLS by default around 2020. 3) If the deprecated protocols are re-enabled, what would constitute a reasonable warning mechanism to inform users that these protocols are going away at some point in the future to pressure users to update to a newer, more secure protocol? Is it reasonable to output that on STDERR any time those protocols are used?

From a library?!

End of life: 3/14/2025, Latest version: 3.1.8

End of life: 3/14/2025, Latest version: 3.1.8

PKCS12 structures contain PKCS7 ContentInfo fields. These fields are optional and can be NULL even if the "type" is a valid value. OpenSSL was not properly accounting for this and a NULL dereference can occur causing a crash. The OpenSSL project did announce a new release, which is assumed to contain this bug fix; that release will be published on Jan 30th.

Reference: https://github.com/openssl/openssl/pull/23362

On Wed, Oct 18, 2023 at 02:30:22PM +0100, Matt Caswell wrote: On 17/10/2023 19:06, Solar Designer wrote: Matt, I'd appreciate it if you (or your team) would also be posting these to oss-security going forward, roughly at the same time with posting them to your project's public lists. Also, more specific Subject lines on these and on the eventual security advisories would be helpful. Thank you! Ok. Are you only interested in release pre-announcements for releases which contain security fixes, or do you want to know about all OpenSSL releases? Only for releases which contain security fixes, please. Thank you!

And for other Open Source project maintainers reading this - it's the same for your projects as well - if you issue pre-announcements of security fixes anywhere public, then please also post them in here.

Alexander

On November 1, 2022, the OpenSSL Project announced the following vulnerabilities: For a description of these vulnerabilities, see OpenSSL Security Advisory [Nov 1 2022]. This advisory is available at the following link:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-openssl-W9sdCc2a

CVE-2022-3602:

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. 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. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. 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.

CVE-2022-3786:

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 a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate 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). 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.

Both the vulnerabilities are fixed in OpenSSL 3.0.7 (Affected 3.0.0,3.0.1,3.0.2,3.0.3,3.0.4,3.0.5,3.0.6).

USN-5488-1 fixed vulnerabilities in OpenSSL. This update provides the corresponding updates for Ubuntu 16.04 ESM. Original advisory details: Chancen and Daniel Fiala discovered that OpenSSL incorrectly handled the crehash script. A local attacker could possibly use this issue to execute arbitrary commands when crehash is run.

The OpenSSL 3.0.4 release introduced a serious bug in the RSA implementation for X8664 CPUs supporting the AVX512IFMA instructions. This issue makes the RSA implementation with 2048 bit private keys incorrect on such machines and memory corruption will happen during the computation. As a consequence of the memory corruption an attacker may be able to trigger a remote code execution on the machine performing the computation. SSL/TLS servers or other servers using 2048 bit RSA private keys running on machines supporting AVX512IFMA instructions of the X8664 architecture are affected by this issue.

Chancen and Daniel Fiala discovered that OpenSSL incorrectly handled the crehash script. A local attacker could possibly use this issue to execute arbitrary commands when crehash is run.