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)

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:

• OpenSSL Vulnerabilities
• CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows
• NCSC-NL/OpenSSL-2022
• MalwareTech/SpookySSLTools

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.

Read more in

• X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602)
• Critical OpenSSL 3.0 Update Released. Patches CVE-2022-3786
• OpenSSL CHANGES

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

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.

Note

• While people are working on performing the diffing of patches to try and understand the impact, OpenSSL 3.0 may not be as widely deployed as the version with Heartbleed. It’s a wait-to-see scenario. A core library like this may still impact many systems. Hopefully, with the advent of SBOM (software bill of material) products, companies can quickly find and attempt to patch these libraries quickly.
• The notice from OpenSSL doesn’t disclose the exact vulnerability, only categorizing it as critical, which means it affects common configurations and is likely to be exploitable. OpenSSL policy is to keep the specific issues private and trigger a new release. Given the prevalence of OpenSSL it makes sense to be careful disclosing the exact issue as there could be an enormous attack surface. What you can do is make sure that you update your OpenSSL installs, and applications with embedded OpenSSL, judiciously after the update is released. Review your software inventory and make a prioritized list, much like you did for Log4J.

Read more in

• Forthcoming OpenSSL Releases
• Prepare Now for Critical Flaw in OpenSSL, Security Experts Warn
• OpenSSL warns of critical security vulnerability with upcoming patch