Critical OpenSSL 3.0 Update Released to Patch CVE-2022-3786, CVE-2022-3602

Updated on 2022-11-06:: Anxiously awaited OpenSSL bug downgraded

The OpenSSL Project announced OpenSSL 3.0.7 this week with a fix for a previously-“critical” security flaw, which the project developer’s downgraded to “high.” The bug could create a denial-of-service condition, or in some cases, remote code execution on an affected client. @pwnallthethings has a good tweet thread explaining more, while @MalwareTechBlog deep-dives in a blog post. Read more:

Anxiously Awaited OpenSSL Vulnerability’s Severity Downgraded From Critical to High
Everything you need to know about the OpenSSL 3.0.7 Patch (CVE-2022-3602 & CVE-2022-3786)

Folks who've been up for a while waiting for this "critical" #openssl vulnerability, here it is. Quick thread of initial thoughts https://t.co/XrAm4YAuUo

— @[email protected] (@pwnallthethings) November 1, 2022

I made a post with some helpful information on the upcoming OpenSSL vulnerability. Will update when more becomes available.https://t.co/XPBwhsiZ2M

— [email protected] (@MalwareTechBlog) November 1, 2022

Updated on 2022-11-04: New tool—openssl-tools

DevOps security firm JFrog has published scanners to test your apps and see if they are vulnerable to the recently patched OpenSSL vulnerabilities CVE-2022-3602 and CVE-2022-3786. Read more: jfrog/jfrog-openssl-tools

Updated on 2022-11-03: Critical OpenSSL 3.0 Update Released. Patches CVE-2022-3786, CVE-2022-3602

As preannounced, OpenSSL released version 3.0.7, which patches two related vulnerabilities rated as “High.” Initially, as part of a preannouncement, the vulnerability was rated “Critical.” OpenSSL 3.0 was initially released in September of last year.

The update patches a buffer overrun vulnerability that happens during the certificate verification. The certificated needs to contain a malicious Punycode encoded name, and the vulnerability is only triggered AFTER the certificate chain is verified. An attacker first needs to be able to have a malicious certificate signed by a certificate authority the client trusts. This does not appear to be exploitable against servers. For servers, this may be exploitable if the server requests a certificate from the client (mTLS) [1] . OpenSSL also published a blog post with details here: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/

In short: While this is a potential remote code execution vulnerability, the requirements to trigger the vulnerability are not trivial, and I do not see this as a “Heartbleed Emergency”. Patch quickly as updated packages become available, but beyond this, no immediate action is needed. Read more: Critical OpenSSL 3.0 Update Released. Patches CVE-2022-3786, CVE-2022-3602

Updated on 2022-11-02: OpenSSL bug not a big deal

The OpenSSL project published a security update on Tuesday to fix two vulnerabilities tracked as CVE-2022-3786 and CVE-2022-3602, touted last week as the first “critical”-level vulnerabilities the project was patching in the last six years. But as the OpenSSL project explained in a blog post, the vulnerabilities were not as dangerous as everyone was led to believe last week, and the two had their severity rating downgraded to “high.” While not as widespread as initially feared, users are still advised to patch both issues. For defenders, the Dutch NCSC maintains a list of software vulnerable to this vulnerability, and researcher Marcus Hutchins published scripts for scanning your network/software and checking to see if it’s affected. Read more:

Updated on 2022-11-01: OpenSSL Patches Punycode Vulnerability in OpenSSL 3.0

Today, OpenSSL released OpenSSL 3.0.7. This version patches a buffer overrun vulnerability that can be triggered in X.509 certificate verification. To exploit the vulnerability, the attacker would need to obtain a valid signature from a trusted certificate authority for a malicious certificate. The vulnerability is triggered by a malformed Punycode encoded domain name either in a hostname or the domain part of an email address included in the certificate. Exploitation will result in a crash (denial of service) or could also lead to remote code execution. OpenSSL initially rated the vulnerability as “Critical” but now downgraded it to “High.”

Note

Looks “not bad.” Exploitation seems to be unlikely given the requirement for a valid signature from a trusted certificate authority. The remote code execution is only likely for a malformed Punycode email address. Patch this one as updated packages become available, but you can stand down from “Heartbleed status.”
OpenSSL released two patches that were originally deemed critical. It appears that during the internal disclosure process, many of the operating system vendors have responded with comments and potentially PoC code that identifies many of the memory protections and compiler protections that would make reaching this bug for true exploitability harder than thought (potentially impossible, although that’s an absolute that I would never claim). There is, however, a chance that OpenSSL 3.0 is in use in network gear such as firewalls, VPNs, switches, and routers. Most of these devices do NOT offer memory protections as they can’t afford to spend the computational cost of doing so. The only saving grace(s) is that the vendor may not have moved to OpenSSL 3.0 yet, and the customers may not have upgraded to software with the vulnerability. The only true way to tell is to wait for vendor disclosures. On a lark, I went ahead and looked at the latest Cisco ASA 9.18 version’s disclosure documentation [www.cisco.com: Open Source Used In ASA 9.18.1 (PDF)], and it appears that they are still disclosing 0.9 train and 1.1.X trains in that document. Please do not take this as an assured fact. Every vendor will have to perform this library search. If you are looking at your own servers, there will be scanners for this it’s probably just too early to tell.
For most organizations, I recommend taking a step back from the gritty details and ensure you have an inventory of where you leverage OpenSSL and what versions. For OpenSSL 3.x solutions, see where and how to apply the patch. Then you can focus on understanding the implementation of the solutions using OpenSSL 3.x that cannot be patched yet and see if there is a possibility of those implementations being exploitable. I posted the most useful resources I found thus far here.

OpenSSL vulnerability resources I found most useful:
– Advisory: https://t.co/PLJmG9FtsC
– Blog: https://t.co/bToaP4Tgso
– Post from @sans_isc: https://t.co/rMrwybFvIA
– CVEs in question: CVE-2022-3602 & CVE-2022-3786

TL:DR Not a big deal, inventory where you have OpenSSL 3

— Jorge Orchilles 🦄 (@jorgeorchilles) November 1, 2022

Read more in

Updated on 2022-10-27: Upcoming OpenSSL critical update

The OpenSSL project announced a major critical-rated security update for its library for next week, on November 1. Read more: Forthcoming OpenSSL Releases

This will be OpenSSL's first "CRITICAL" vulnerability since 2016. Examples of "CRITICAL" vulnerabilities include "significant disclosure of the contents of server memory (potentially revealing user details), … https://t.co/fsykqaovvY

— Andrew Ayer (@__agwa) October 25, 2022

Overview

OpenSSL plans to release an update next week to address a critical vulnerability in the cryptographic library. The flaw affects OpenSSL versions 3.0.0 through 3.0.6. OpenSSL will release version 3.0.7 on Tuesday, November 1. The last time OpenSSL was faced with a critical vulnerability was the Heartbleed vulnerability, which was disclosed in 2014.