OpenSSL today released a fix for a critical high-severity vulnerability that project maintainers warned about last week.
After days of speculation, infosec professionals and armchair bug hunters were given more trick than trick on November 1: two CVE-flagged security issues, both rated “high” severity, to be fixed. A flaw was previously rated as “critical,” although it has now been downgraded as it will require a high degree of technical skill to exploit, if possible against a realistic target.
And now to be very clear: this is not a slam for the OpenSSL team. This drama is not their fault. Technically, the initially critical bug was likely a critical issue as it is a remote code execution vulnerability, although it will be difficult to abuse.
However, it is not every day that you are warned of a critical flaw in OpenSSL – an important software library generally used by various apps and servers to encrypt data across networks and the Internet – and therefore infosec providers, blogs and influencers. they couldn’t help but advertise it, promising live feeds of pain and misery when the details of the holes are revealed. And when these details were announced today, as expected, it all seemed a bit over the top. That said, patches should be applied as needed whenever possible.
As infosec guru Marcus Hutchins tweeted, it wasn’t worth wringing your hand:
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 to 10 of what the panic was worth, I would rate less than zero.
– Marcus Hutchins (@MalwareTechBlog) November 1, 2022
Both bugs affect only a small subset of OpenSSL implementations: software that uses versions 3.0.0 (released September 2021) to 3.0.6. Apps, servers, and operating systems running these versions should upgrade to OpenSSL 3.0.7, which fills the gaps.
The first vulnerability, found as CVE-2022-3602, can be exploited by a malicious email address in an encryption certificate to overflow into the attacker’s controlled four-byte stack causing the application or server to crash or potentially leads to remote code execution (RCE) – but only after certificate validation. This would require “either a CA that has signed the malicious certificate or that the application continues verifying the certificate despite failing to create a path to a trusted issuer,” according to the OpenSSL security advisory.
Therefore, 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. Getting control would somehow involve configuring the stack to use the overwritten bytes to hijack the program flow. Many platforms offer stack buffer overflow protections that would mitigate this RCE risk, the OpenSSL warning noted. The software must be created with stack buffer overflow detection in place. Not a lot of software still uses OpenSSL 3.
And so, without ruining ourselves, the exploitation here will be limited.
Although the pre-announcement on October 25 tagged this vulnerability as critical, the open source project team ultimately downgraded it to high based on the number of steps an attacker would have to take to obtain RCE.
‘If the stars align’
“In reality, exploiting this will be very, very difficult even for very competent exploit writers and will require a large number of relatively unlikely scenarios to all align in order for the exploit writer to be successful.” noticed security wizard Matt ‘Pwn All The Things’ Tait, who shared a flaw analysis here.
“That said, if the stars line up, the attacker takes control of the car,” he added. “So don’t ignore it. Patch it for sure. But I wouldn’t lose sleep on it either.”
One of the main reasons the bug was initially labeled critical was that the OpenSSL team cannot guarantee that people’s systems have the necessary protections to thwart buffer overflow exploitation in this case, and so they were wrong to excess of caution. “We have no way of knowing how each platform and compiler combination arranged the buffers on the stack, and so remote code execution may still be possible on some platforms,” the security team said.
According to project policy, a bug can be considered critical if RCE is “likely in common situations”.
However, during the pre-notification week, after reviewing technical details and receiving input from groups running tests on the defect, RCE did not seem more 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 is a second high severity vulnerability, CVE-2022-3786, which OpenSSL has fixed in version 3.0.7. Like the first bug, this 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 create a malicious email address in a certificate to overflow an arbitrary number of bytes containing ‘.’ character (decimal 46) in the stack, “according to the security advisory. “This buffer overflow could cause a crash (causing a Denial of Service).”
Lesson learned?
While neither vulnerability should inspire Heartbleed-level panic, said Clair Tills, senior research engineer at Tenable. The register there are lessons to be learned from “pre-announcement and rampant nail biting” until the release of OpenSSL, 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,” said Tills. “How difficult was it for them to determine which version of OpenSSL they had implemented or if any software they relied on 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 these questions, upgrade to the fixed version of OpenSSL, if you’re using OpenSSL 3, and then go for a drink to celebrate that it 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 is unaffected by this.
For more details see the FAQ. No exploitation or working exploit code has been observed in nature. ®
