OpenSSL Downgrades Horror Bug After Week Of Panic, Hype

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

After days of speculation, infosec professionals and armchair bug hunters received more of a trick than a treat on November 1: two CVE-tagged security issues, both rated “high” severity, to patch. One flaw was earlier rated “critical,” though it has now been downgraded as it will require a high degree of technical skill to exploit, if that’s even possible at all against a realistic target.

And now to be very clear: this isn’t a slam on the OpenSSL team. This drama isn’t their fault. Technically, the initially critical bug was arguably a critical issue as it’s a remote-code execution vulnerability albeit one that will be challenging to abuse.

However, it’s not every day we’re warned of a critical flaw in OpenSSL – an important software library typically used by various apps and servers to encrypt data over networks and the internet – and so infosec vendors and blogs and influencers couldn’t help but hype it up, promising live feeds of pain and misery when details of the holes are revealed. And when those details were announced today, as planned, it all seemed a little overblown. That said, patches should be applied as necessary when able.

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

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

— Marcus Hutchins (@MalwareTechBlog) November 1, 2022

Both bugs only affect a small subset of OpenSSL deployments: software using versions 3.0.0 (released September 2021) to 3.0.6. Apps, servers, and operating systems using those versions should upgrade to OpenSSL 3.0.7, which plugs the holes.

The first vulnerability, tracked as CVE-2022-3602, can be exploited by a maliciously long email address in an encryption certificate to overflow 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 is validated. This would require “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,” 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, and cause that target to crash or possibly gain control of it. Gaining control would involve somehow setting up the stack to use the overwritten bytes to hijack the flow of the program. Many platforms offer stack buffer overflow protections that would mitigate this risk of RCE, the OpenSSL advisory noted. Software should be built with stack buffer overflow detection in place. Not that much software is using OpenSSL 3 yet.

And so, without jinxing ourselves, exploitation here is going to be limited.

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

‘If the stars align’

“Actually exploiting this will be really really hard even for very competent exploit writers, and will require a large number of relatively unlikely scenarios to all align for the exploit writer for it to pan out,” noted security wizard Matt ‘Pwn All The Things’ Tait, who shared an analysis of the flaw here.

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

A key reason why the bug was initially labeled critical was that the OpenSSL team can’t guarantee people’s systems have the necessary protections in place to thwart the buffer overflow exploitation in this case, and so erred on the side of caution. We “have no way of knowing how every 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.

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

However, during the pre-notification week, after looking at the technical details and receiving input from groups performing testing on the flaw, RCE no longer seemed likely in common situations, the security team said. This is why the team downgraded the vulnerability to high-severity on November 1, they added.

There’s a second high-severity vulnerability, CVE-2022-3786, that OpenSSL fixed in version 3.0.7. Like the first bug, this one follows a similar path to exploit, and can trigger a buffer overrun leading to a crash, but again only after a certificate has been signed or accepted.

“An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the ‘.’ character (decimal 46) on the stack,” according to the security advisory. “This buffer overflow could result in a crash (causing a denial of service).”

Lesson learned?

While neither vulnerability should inspire Heartbleed-level panic, Tenable senior research engineer Claire Tills told The Register there are lessons to be learned from “pre-announcement and rampant nail biting” up to the OpenSSL release, which “revealed a couple of high severity flaws that are not easy to exploit and only affect 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 whether any software on which they rely was vulnerable? Were their communication channels mature enough to get correct information to the people who needed it as soon as it was available?”

To answer those questions, upgrade to the fixed OpenSSL version, if you’re using OpenSSL 3 — and then go 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, such as Google’s BoringSSL which isn’t affected by this.

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

READ MORE HERE