Security experts described two highly anticipated vulnerabilities that the OpenSSL Project team patched Tuesday as issues that need to be addressed quickly, but not necessarily meriting a drop-everything-else type of emergency response.
The release of version 3.0.7 of the almost ubiquitously used cryptographic library addresses two buffer overflow vulnerabilities, which exist in OpenSSL versions 3.0.0 to 3.0.6.
Leading up to the disclosure, security experts had warned that one of the issues, originally characterized as a “critical” remote code-execution issue, could present a Heartbleed-level, all-hands-on-deck problem. Thankfully, that doesn’t seem to be the case — and in disclosing the flaw, the OpenSSL project team said it had decided to downgrade the threat to “high” based on feedback from organizations that had tested and analyzed the bug.
A Pair of Buffer Overflows
The first bug (CVE-2022-3602) could indeed — under a specific set of circumstances — enable RCE, which originally led some security experts to worry that the flaw could have industry-wide repercussions. But it turns out that there are mitigating circumstances: For one, it’s difficult to exploit, as explained below. Also, not all systems are impacted.
Specifically, only browsers that support OpenSSL 3.0.0 through 3.0.6, such as Firefox and Internet Explorer, are impacted at this time, according to Mark Ellzey, senior security researcher at Censys; notably unaffected is Google Chrome, which is the leading Internet browser.
“The impact is expected to be minimal due to the complexity of the attack and the limitations in how it can be carried out,” he says. “Organizations should brush up on their phishing training and keep an eye on threat intelligence sources to ensure they are prepared if they are targeted by an attack such as this.”
To boot, Alex Ilgayev, lead security researcher at Cycode, noted that the flaw can’t be exploited on certain Linux distributions; and, many modern OS platforms implement stack overflow protections to mitigate against threats like these in any event, Ilgayev says.
The second vulnerability (CVE-2022-3786), which was uncovered while a fix for the original flaw was being developed, could be used to trigger denial of service (DoS) conditions. The OpenSSL team assessed the vulnerability as being of high severity but ruled out the possibility of it being used for RCE exploitation.
Both vulnerabilities are tied to a functionality called Punycode for encoding internationalized domain names.
“Users of OpenSSL 3.0.0 – 3.0.6 are encouraged to upgrade to 3.0.7 as soon as possible,” the OpenSSL team said in a blog accompanying the bug disclosure and release of the new version of the cryptographic library. “If you obtain your copy of OpenSSL from your Operating System vendor or other third party then you should seek to obtain an updated version from them as soon as possible.”
Not Another Heartbleed
The bug disclosure is sure to tamp down — for the moment, at least — the widespread concern sparked by the OpenSSL team’s notification last week of its then-impending bug disclosure. The description of the first flaw as being “critical,” in particular, had prompted several comparisons to 2014’s “Heartbleed” bug — the only other bug in OpenSSL to earn a critical rating. That bug (CVE-2014-0160) impacted a wide swathe of the Internet and even now has not be fully addressed at many organizations.
“Heartbleed was exposed by default on any software that used a vulnerable version of OpenSSL, and it was very easily exploitable by attackers to see cryptographic keys and passwords stored in server memory,” says Jonathan Knudsen, head of global research at Synopsys Cybersecurity Research Center. “The two vulnerabilities just reported in OpenSSL are serious but not of the same magnitude.”
OpenSSL Bugs Are Hard to Exploit…
To exploit either of the new flaws, vulnerable servers would need to request client certificate authentication, which is not the norm, Knudsen says. And vulnerable clients would need to connect to a malicious server, which is a commonplace and defensible attack vector, he says.
“Nobody’s hair should be on fire about these two vulnerabilities, but they are serious and should be handled with appropriate speed and diligence,” he notes.
In a blog post, the SANS Internet Storm Center meanwhile described the OpenSSL update as fixing a buffer overrun during the certificate verification process. For an exploit to work, the certificate would need to contain a malicious Punycode-encoded name, and the vulnerability would be triggered only after the certificate chain is verified.
“An attacker first needs to be able to have a malicious certificate signed by a certificate authority the client trusts,” SANS ISC noted. “This does not appear to be exploitable against servers. For servers, this may be exploitable if the server requests a certificate from the client.”
Bottom line: The likelihood of exploitation is low since the vulnerability is complex to exploit, as is the flow and requirements to trigger it, Cycode’s Ilgayev says. Plus, it affects a relatively small number of systems, compared to those using pre-3.0 versions of OpenSSL.
…But Do Be Diligent
At the same time, it is important to keep in mind that hard-to-exploit vulnerabilities have been exploited in the past, Ilgayev says, pointing to a zero-click exploit that the NSO Group developed for a vulnerability in iOS last year.
“[Also], like the OpenSSL team says, there is ‘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,” he cautions.
And indeed, Ellzey outlines one scenario for how attackers could exploit CVE-2022-3602, the flaw that OpenSSL team had originally assessed as critical.
“An attacker would host a malicious server and attempt to get victims to authenticate to it with an application vulnerable to OpenSSL v3.x, potentially through traditional phishing tactics,” he says, although the scope is limited due to the exploit being predominantly client-side.
Vulnerabilities such as this highlight the importance of having a software bill of materials (SBOM) for every binary used, Ilgayev notes. “Looking at package managers is not enough as this library could be linked and compiled in various configurations that will affect the exploitability,” he says.
Source: www.darkreading.com