The “S” in HTTPS stands for “secure,” but a newly disclosed pair of software flaws in one of the most popular open-source cryptographic libraries shows that assurance can come with a caveat.
The OpenSSL Project has revealed a pair of high-severity vulnerabilities in the OpenSSL library used by many organizations to encrypt traffic between their servers and the people visiting them in their browsers.
Many cybersecurity companies braced themselves for what was expected to be the first “critical” vulnerability discovered in OpenSSL in the last six years. But despite the OpenSSL Project’s Oct. 25 announcement that it would reveal a critical vulnerability Nov. 1 (along with its patch), the updates released on Tuesday apply to a pair of flaws that don’t meet the group’s criteria for a critical designation.
“Pre-announcements of CVE-2022–3602 described this issue as CRITICAL,” OpenSSL said in an advisory. “Further analysis based on some of the mitigating factors described [in this advisory] have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.”
At stake is much more than semantics. The OpenSSL Project introduced the “critical” designation for vulnerabilities, which indicates that a flaw “affects common configurations” and is “also likely to be exploitable,” after the infamous Heartbleed bug was discovered and disclosed by Google Security in 2014. Wired reported at the time that Heartbleed “broke the internet” — and that was before the HTTPS protocol became as common as it is today.
So it’s easy to see why so many security pros tripped over themselves to warn about the new flaws, labeled CVE-2022–3602 and CVE-2022–3786, ahead of their disclosure. While they didn’t turn out to be Heartbleed 2.0, such far-reaching flaws in bedrock cryptographic code have cropped up in the past — and they can be very tricky and time-consuming to fix.
What’s behind the bugs
Odds are that everyone on the internet has relied on OpenSSL before.
The OpenSSL Project describes its eponymous library as “a robust, commercial-grade, full-featured toolkit for general-purpose cryptography and secure communication.” At a practical level, that means OpenSSL is often responsible for securing the connection between a browser and a server over the HTTPS protocol.
That encryption allows people to securely check their email, shop online and perform other everyday tasks they don’t want to have exposed to anyone in between them and the connected server. A vulnerability affecting OpenSSL is likely to affect at least some of these connections — and that means exploiting these flaws can leak the information that’s supposed to be protected by this library.
In this case, the OpenSSL Project dubbed CVE-2022–3602 as “X.509 Email Address 4-byte Buffer Overflow” and CVE-2022–3786 as “X.509 Email Address Variable Length Buffer Overflow.” The former was discovered by “Polar Bear” on Oct. 17; the latter was discovered by Viktor Dukhovni on Oct. 18 while investigating the other flaw. Both bugs are believed to have been addressed in OpenSSL 3.0.7, which the group released on Tuesday.
The OpenSSL Project said “an attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack” by exploiting CVE-2022–3602 or “overflow an arbitrary number of bytes containing the `.’ character (decimal 46) on the stack” by using a similar technique to exploit CVE-2022–3786. Both could result in crashes for denial of service attacks; CVE-2022–3602 can also lead to remote code execution.
Bad but not critical
So why did the OpenSSL Project downgrade the vulnerabilities’ severity? In a separate blog post, the group said it received feedback from several organizations in the past week, and those researchers found slim chance attackers could exploit these flaws to enable remote code execution.
“We are not aware of any working exploit that could lead to remote code execution,” The OpenSSL Project said, “and we have no evidence of these issues being exploited as of the time of release of this post.”
Even if these vulnerabilities had retained their “critical” rating, they were unlikely to be as disruptive as Heartbleed because they affect a limited number of versions of OpenSSL. The OpenSSL Project said these vulnerabilities affect OpenSSL 3.0.0 to 3.0.6 but not their far more popular predecessors, OpenSSL 1.1.1 and 1.0.2.
Censys reported that as of Oct. 30, some 1.8 million “unique hosts have one or more services broadcasting that they use OpenSSL.” But only 0.4 percent of those hosts are running a version of the library affected by these vulnerabilities. The other 99.6 percent of the hosts scanned by the company use a different version of OpenSSL that isn’t vulnerable.
The Netherlands’ National Cyber Security Centre (NCSC-NL) has also been investigating popular operating systems, software and services to determine whether they’re affected by these vulnerabilities. That work is ongoing at time of writing, but the vast majority of the products examined by the Dutch ministry use a version of OpenSSL that isn’t affected.
Rapid7 said in a blog post that neither of these vulnerabilities “lend themselves well to widespread exploitation.” The attack surface management company Randori reached a similar conclusion, saying “it is not believed that these vulnerabilities will be exploited in real-world scenarios.” Even the cloud security firm Datadog, which published a proof of concept exploit that can be used in denial of service attacks on Windows systems, said these flaws are unlikely to be used en masse.
“My view is that the circumstances and complexity of exploitation here will make this a relatively unattractive exploit for attackers to target,” Matt Tait, better known as “Pwn All the Things,” said in a blog post about the vulnerabilities. “Companies should, of course, update vulnerable software. But exploitation will be costly and program-specific, if it takes place at all.”
To summarize: The vulnerabilities aren’t as severe as expected, affect versions of the library that practically nobody has exposed to the internet and seem to be more likely to cause a crash than remote code execution. That might change as more researchers examine these flaws, but for now, the consensus appears to be that these flaws aren’t the next Heartbleed.
“We still consider these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible,” The OpenSSL Project said.
