High-severity OpenSSL vulnerabilities fixed (CVE-2022-3602, CVE-2022-3786)
Version 3.0.7 of the popular OpenSSL cryptographic library is out, with fixes for CVE-2022-3602 and CVE-2022-3786, two high-severity buffer overflow vulnerabilities in the punycode decoder that could lead to crashes (i.e., denial of service) or potentially remote code execution.
CVE-2022-3602, whose existence was preannounced by the OpenSSL Project team a week ago, has luckily turned out to be less dangerous than initially thought.
So the much feared *Critical* #OpenSSL turns out to be "just" a *High* impact #DoS vulnerability.
A controversial thing because of all the hype this created, but always better to see a critical vulnerability become less important than the other way aroundhttps://t.co/qUqICmBXQ2— Gitworm (@Gi7w0rm) November 1, 2022
About CVE-2022-3602 and CVE-2022-3786
CVE-2022-3602 was discovered by a security researcher (and prolific bug hunter) who goes by handles Polar Bear or SandboxEscaper, and has been reported on October 17. After its disclosure to the OpenSSL Project team, OpenSSL committer Viktor Dukhovni found “a second independently triggerable issue” – CVE-2022-3786.
Both can be exploited to trigger a buffer overrun in X.509 certificate verification, specifically in name constraint checking, by an attacker that crafts a malicious email address in a certificate.
“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,” the team explained.
Fortunately, the buffer overrun can be triggered “only 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.”
This, coupled with the fact that many platforms implement stack overflow protections, make the flaws not easily exploitable.
According to the team, there is no evidence of either of the flaws being exploited by attackers.
What now?
The vulnerabilities have been fixed in OpenSSL v3.0.7, and don’t affect OpenSSL 1.1.1s or earlier versions in that branch.
Last week’s preannouncement has sent the cybersecurity community in a tizzy, but they can now breathe a sigh of relief.
The Dutch Nationaal Cyber Security Centrum (NCSC-NL) has compiled and will be regularly updating a list of software (un)affected by the vulnerabilities. Users are urged to check it out to see whether they are using some of the affected software, and to upgrade when vendors release a version with a patch.
Censys has created an interactive dashboard showing (some of the) servers running a version of OpenSSL greater than or equal to 3.0.0 (i.e., a vulnerable OpenSSL version).
The OpenSSL team still encourages users to upgrade to a new version as soon as possible, but the urgency can be toned down.
“Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication,” the OpenSSL team noted, and added that users operating TLS servers may consider disabling TLS client authentication until fixes can be applied.
“Exploiting this vulnerability requires quite a bit of set up and a number of factors to fall into place before it could be leveraged. Organizations should perform analysis to see if they are impacted, although there are relatively limited affected systems, as the attack primarily impacts the client-side, not the server. Technologies like SCA (software composition analysis) tools can help organizations identify where these components are so they can create an inventory and then a plan for remediation based on risk,” commented Victor Wieczorek, VP of App Sec, Threat & Attack Simulation at GuidePoint Security.