"critical" security vulnerability in OpenSSL

I wanted to update OpenWRT today but should I wait a until this has been addressed?

Details of this "critical" security vulnerability in OpenSSL aren't yet
public but should see its embargo lifted next Tuesday. We'll see how
nasty this latest OpenSSL vulnerability is on Tuesday but it's ranked 
critical and the Red Hat Product Security team advised in delaying 
Fedora 37. 

source:

OpenWrt does not use openssl by default.
(Wolfssl is the current default SSL lib)

And you probably have no idea if your current router OS is affected too.

I know but OpenVPN requires OpenSSL and WolfSSL is still experimental in that regard:

openvpn-wolfssl - 2.5.7-3 - Open source VPN solution using WolfSSL \(experimental\))

My question remains the same, should I wait until this has been addressed?

Well, as nobody here knows the unpublished details about that new bug in openssl, it is hard to say anything.

But possibly the bug only concerns openssl 3.0 series but not the old 1.1.1 that we are using. They are going to publish also 1.1.1s next week, but explicitly say that it is not affected.

3 Likes

This logic is beyond me... So 1 product has a bug in a specific version. Are you implying that a completely different piece of software written by different people has the same bug? Why would that be? It feels like: car manufacturer x has a problem with brakes, so all car manufacturers have made the same mistake

1 Like

Openssl is one of the three alternative SSL libraries used by OpenWrt. The default is currently wolfssl, but also openssl and mbedtls can be used. So, if somebody has configured OpenWrt to use specifically openssl, the question is quite valid. Quite many of the VPN packages support only one of these alternative SSL libs, so there may not be much choice.

It actually is like like "brakes of type XYZ from the brake manufacturer ABC have been noted to all have faults. If my car has the XYZ brakes, it has the fault."

( But we use the unaffected 1.1.1 brakes instead of the faulty 3.0.x brakes)

6 Likes

Thank you, then I will patiently wait :smiley:

I'm curious, what are you waiting for, exactly?

(I'm just trying to make sure I didn't miss something important regarding security here.)

1 Like

Probably since no car manufacturer actually make brakes to begin with.
Guess about 95% of all world todays cars brakes are ATE or Bosch brakes so if they make a fault a lot of cars get a fault.

https://www.zdnet.com/article/openssl-warns-of-critical-security-vulnerability-with-upcoming-patch/
This bug seems to be OpenSSL 3 only.

The CVE-details, and its probably nothing, but you never know.

1 Like

https://www.openssl.org/news/secadv/20221011.txt
https://www.openssl.org/news/vulnerabilities.html
https://www.opencve.io/cve?vendor=openssl&cvss=&search=openssl+1.1.1

No extra details afaic see

Yes it is:

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. Reported by Polar Bear.

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. Reported by Viktor Dukhovni.

This has been downgraded to low severity anyway, see https://www.theregister.com/2022/11/01/openssl_downgrades_bugs/

1 Like

Phoronix also mentioned 3.x only.

Well, as OpenSSL itself specified "3.0 only" in the mailing messages that I linked four days ago, that part is pretty clear.

1.1.1 is not susceptible to the CVE that is being fixed in 3.0:

2 Likes