OpenSSL Downgrades Scary Bug After Week of Speculation

OpenSSL today issued a patch for a critical, high-severity vulnerability that project maintainers warned about last week.

After days of speculation, infosec pros and armchair hunters got more of a trick than a treat on Nov. 1: two CVE-tagged security issues, both rated “high” severity, to fix. A bug was previously rated as “critical”, though it has now been downgraded as it will require a high degree of technical skill to exploit, if even possible against a realistic target.

And now to be very clear: this is not a slam on the OpenSSL team. This drama is not their fault. Technically, the initially critical bug was arguably a critical problem because it is a remote code execution vulnerability although it will be a challenge to exploit.

However, it’s not every day we’re alerted to a critical flaw in OpenSSL—a key software library commonly used by various apps and servers to encrypt data over networks and the Internet—so infosec vendors and blogs and influencers couldn’t help but hype up it and promises vivid streams of pain and misery as details of the holes are revealed. And when those details were announced today, as planned, it all seemed a little over the top. That said, band-aids should be applied as needed whenever possible.

As infosec guru Marcus Hutchins tweeted, it wasn’t worth the hand-wringing:

Based on the technical details of the OpenSSL vulnerability, it could theoretically lead to RCE, but in practice it would be extremely unlikely or even impossible. On a scale of 1-10 of whether it was worth the panic, I would give it less than zero.

— Marcus Hutchins (@MalwareTechBlog) November 1, 2022

Both bugs affect only a small subset of OpenSSL distributions: software using versions 3.0.0 (released September 2021) through 3.0.6. Apps, servers and operating systems using these versions should be upgraded to OpenSSL 3.0.7, which closes the holes.

The first vulnerability, tracked as CVE-2022-3602, can be exploited by a maliciously long email address in an encryption certificate to flood four attacker-controlled bytes on the stack that crashes the application or server—or potentially leads to remote code execution (RCE)— but only after the certificate has been validated. This would require “either a certificate authority to have signed the malicious certificate or for the application to continue certificate verification even though a path to a trusted issuer has not been established,” according to the OpenSSL security advisory.

Thus, a malicious app or server could send a specially crafted certificate, signed by a CA or otherwise accepted by the recipient, to a vulnerable server or client, causing that target to crash or possibly gain control of it. Gaining control would mean somehow setting the stack to use the overwritten bytes to hijack the program’s flow. Many platforms offer stack buffer overflow protections that would reduce this risk of RCE, the OpenSSL advisory noted. Software should be built with stack buffer overflow detection in place. Not much software uses OpenSSL 3 yet.

And so, without confusing ourselves, the exploitation here will be limited.

While the October 25 preview marked this vulnerability as critical, the open source project team downgraded it to high based on the number of steps an attacker would need to take to achieve RCE.

“If the Stars Align”

“Exploiting this is going to be really, really hard even for very competent exploit writers, and will require a large number of relatively unlikely scenarios to all fit in for the exploit writer to pull off.” noted security wizard Matt ‘Pwn All The Things’ Tait, who shared an analysis of the bug here.

“That said, if the stars align, the attacker takes over the machine,” he added. “So don’t ignore it. Patch it for sure. But I wouldn’t lose any sleep over it either.”

A key reason why the bug was initially marked as critical was that the OpenSSL team cannot guarantee that people’s systems have the necessary protections in place to counter the buffer overflow exploit in this case, and so be cautious. We “have no way of knowing how each platform and compiler combination has arranged the buffers on the stack and therefore remote code execution may still be possible on some platforms,” ​​the security team said.

According to the project’s policy, a bug can be considered critical if the RCE is “likely in common situations.”

But during pre-reporting this week, after looking at the technical details and getting input from groups performing tests on the bug, RCE no longer seemed likely in normal situations, the security team said. That’s why the team downgraded the vulnerability to high severity on Nov. 1, they added.

There is a second serious vulnerability, CVE-2022-3786, which OpenSSL fixed in version 3.0.7. Like the first bug, this one follows a similar path to exploitation, and can trigger a buffer overflow that leads to a crash, but again only after a certificate has been signed or accepted.

“An attacker could create a malicious email address in a certificate to flood an arbitrary number of bytes containing the ‘.” character (decimal 46) onto the stack,” according to the security advisory. “This buffer overflow can result in a crash (causing an overload protection).”

Learning?

While neither vulnerability should inspire Heartbleed-level panic, Tenables senior research engineer Clair Tills said The registry there are lessons to be learned from “pre-reports and rampant nail-biting” leading up to the OpenSSL release, which “revealed a couple of high-severity flaws that are not easily exploitable and affect only a small subset of OpenSSL implementations.”

“This is an opportunity for organizations to evaluate their response processes and understand what can be improved,” Tills said. “How difficult was it for them to determine which version of OpenSSL they had deployed, or if any software they relied on was vulnerable? Were their communication channels mature enough to get the correct information to the people who needed it as soon as it was available ?”

To answer these questions, upgrade to the fixed OpenSSL version if you’re using OpenSSL 3 – and have a drink to celebrate that this wasn’t as bad as we all feared. Oh, and of course we should mention: there are alternatives to OpenSSL, like Google’s BoringSSL that are not affected by this.

For more information, see the FAQ. No exploit or working exploit code has been observed in the wild. ®