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.

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.

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

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

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.

Integer overflow in the MDC2Update function in crypto/mdc2/mdc2dgst.c in OpenSSL before 1.1.0 allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact via unknown vectors.

The Network Security Services (NSS) library before 3.12.3, as used in Firefox; GnuTLS before 2.6.4 and 2.7.4; OpenSSL 0.9.8 through 0.9.8k; and other products support MD2 with X.509 certificates, which might allow remote attackers to spoof certificates by using MD2 design flaws to generate a hash collision in less than brute-force time. NOTE: the scope of this issue is currently limited because the amount of computation required is still large.

OpenSSL could provide weaker than expected security, caused by a carry propagation flaw in the MIPS32 and MIPS64 squaring procedure. An attacker could exploit this vulnerability to launch further attacks on the system

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!

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

Last updated 24 July 2024

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)

Server or client applications that call the SSLcheckchain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signaturealgorithmscert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Fixed in OpenSSL 1.1.1g (Affected 1.1.1d-1.1.1f).

openssl.js was a malicious module published with the intent to hijack environment variables. It has been unpublished by npm.

In OpenSSL 1.1.0 before 1.1.0c, TLS connections using -CHACHA20-POLY1305 ciphersuites are susceptible to a DoS attack by corrupting larger payloads. This can result in an OpenSSL crash. This issue is not considered to be exploitable beyond a DoS.

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.

In OpenSSL 1.1.0 before 1.1.0c, applications parsing invalid CMS structures can crash with a NULL pointer dereference. This is caused by a bug in the handling of the ASN.1 CHOICE type in OpenSSL 1.1.0 which can result in a NULL value being passed to the structure callback if an attempt is made to free certain invalid encodings. Only CHOICE structures using a callback which do not handle NULL value are affected.

Because of an implementation bug the PA-RISC CRYPTOmemcmp function is effectively reduced to only comparing the least significant bit of each byte. This allows an attacker to forge messages that would be considered as authenticated in an amount of tries lower than that guaranteed by the security claims of the scheme. The module can only be compiled by the HP-UX assembler, so that only HP-UX PA-RISC targets are affected. Fixed in OpenSSL 1.1.0h (Affected 1.1.0-1.1.0g).

The Diffie-Hellman key-exchange implementation in OpenSSL 0.9.8, when FIPS mode is enabled, does not properly validate a public parameter, which makes it easier for man-in-the-middle attackers to obtain the shared secret key by modifying network traffic, a related issue to CVE-2011-1923.

muttssl.c in mutt 1.5.19 and 1.5.20, when OpenSSL is used, does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.

During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL 1.1.0 before 1.1.0e to crash (dependent on ciphersuite). Both clients and servers are affected.

OpenSSL could allow a local attacker to bypass security restrictions, caused by the building of . mingw programs or Windows programs with world writable path defaults. An attacker could exploit this vulnerability to modify default configuration, insert CA certificates, modify (or even replace) existing engine modules.

A denial of service flaw was found in the way OpenSSL parsed certain ASN.1-encoded data from BIO (OpenSSL's I/O abstraction) inputs. An application using OpenSSL that accepts untrusted ASN.1 BIO input could be forced to allocate an excessive amount of data.

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.)