On November 1, the OpenSSL Project released version 3.0.7 of OpenSSL, fixing two severe security vulnerabilities in the 3.x branch of OpenSSL. All versions of 3.x prior to 3.0.7 are vulnerable and should be upgraded ASAP.
Malicious email address as trigger
Both vulnerabilities allow for a stack overflow in the X.509 certificate verification process and can be triggered by a malicious email address in the certificate. The error is in the name constraint checking code. The vulnerabilities illustrate how Machine Identity Management and other PKI operations have become critical infrastructure in enterprises that must be protected. Downtime in certificate and other authentication operations could cripple a business.
The more severe vulnerability, “X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602),” could allow an attacker to control four bytes on the stack. This could result in a crash and denial of service, and potentially remote code execution.
The other vulnerability, “X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786),” could allow an attacker to overflow an arbitrary number of bytes on the stack containing the ‘.’ (period, or decimal 046) character. This could result in a crash and denial of service.
An OpenSSL TLS client could be exploited through this vulnerability by connecting to a malicious OpenSSL server. An OpenSSL TLS server could be exploited if it requests client authentication and a malicious OpenSSL TLS client connects.
Vulnerabilities show that poor machine identity management opens door
Kevin Bocek, VP Ecosystem & Threat Intelligence at Venafi, said, “[w]hether we’re running in the cloud in Azure, using Kubernetes in Amazon AWS, or using Apache in your datacenter, the entire digital business requires safe authentication of machine identities. The vulnerabilities in OpenSSL demonstrate the impact of how poor machine identity management – specifically authenticating machine identities – can open the door to attackers.”
Downgraded to 'High'
A pre-announcement of the update last week characterized the severity of CVE-2022-3602 as “CRITICAL.” Today’s announcement downgrades that to “HIGH” based on mitigating factors in the report. CVE-2022-3786 is also rated “HIGH” for severity. For instance, it is common for systems running critical code, such as OpenSSL, to implement protections against stack overflows, which would catch exploits of this vulnerability. The implementation specifics of the stack layout from the compiler or running platform could also defeat exploits.
Furthermore, according to the security advisory, an exploit of either vulnerability “… 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.”
The 1.x branch of OpenSSL is not affected by these vulnerabilities. The OpenSSL Project also released version 1.1.1s of OpenSSL, but it only addresses a single less-severe bug, which was also in fixed in 3.0.7.
The bug is a regression introduced in the prior version. The old versions might “not [refresh] the certificate data to be signed before signing the certificate.”
OpenSSL used to be the default implementation for all, but there are many other TLS implementations available. Google’s BoringSSL and the OpenBSD Project’s LibreSSL are two prominent ones, and both are forks of OpenSSL. Both forked long before the 3.x branch of OpenSSL and they are not affected by these vulnerabilities.
Not off the hook
"When OpenSSL first announced this patch was coming, I immediately thought back to major vulnerabilities of the past, such as Heartbleed and Log4j," said Mattias Gees, Container Product Lead at Venafi.
The downgrade is "mainly because it doesn’t cause data leakage and the attack vector is relatively small," said Gees.
But this doesn’t mean you're off the hook, according to Gees. The risk of DDoS attacks is still high if servers request client authentication and a malicious server connects.
"Servers that are on OpenSSL 3.0 and are using Client Authentication in a non-trusted environment – such as public facing servers – should patch immediately to ensure they don’t fall victim to DDoS attacks. Servers running in trusted environments should still be patched, but the urgency here is reduced as attacks won’t be effective unless a threat actor manages to infiltrate your network," he said.
(See Datadog for an in-depth explanation of the the issue.)
- OpenSSL Patches New Bug Targeting Encryption [Lessons from Heartbleed]
- The Real Big Story Behind July’s OpenSSL Vulnerability: Why Blind Trust in Certificates Needs to End
- How to Remediate: DROWN Attack – OpenSSL HTTPS Websites are at Risk – Are You?