The OpenSSL Project on Tuesday announced the release of OpenSSL 3.0.7. Everyone was anxiously awaiting to learn the details of the first critical vulnerability discovered since 2016, but the project’s developers decided to downgrade the flaw’s severity rating.
The OpenSSL Project revealed last week that an update for OpenSSL 3.0 would address a critical vulnerability. That flaw is tracked as CVE-2022-3602 and it has been described as a buffer overrun that can be triggered in X.509 certificate verification. Exploitation of the flaw could lead to a denial-of-service (DoS) condition caused by a crash, or even remote code execution.
“An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack,” explains the advisory for CVE-2022-3602.
The advisory adds, “In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.”
However, mitigating factors have led developers to reassess its impact and assign it a ‘high’ severity rating instead of ‘critical’.
“Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler,” the OpenSSL team explained.
In a blog post, the OpenSSL Project shared more information on why the vulnerability’s severity rating was downgraded.
CVE-2022-3602 was originally assessed by the OpenSSL project as CRITICAL as it is an arbitrary 4-byte stack buffer overflow, and such vulnerabilities may lead to remote code execution (RCE).
During the week of prenotification, several organisations performed testing and gave us feedback on the issue, looking at the technical details of the overflow and stack layout on common architectures and platforms.
Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution.
Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.
However as OpenSSL is distributed as source code 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.
OpenSSL 3.0.7 also patches another similar high-severity vulnerability, CVE-2022-3786, which can result in a crash and a DoS condition.
While none of the security holes are critical, users are still encouraged to update their dependencies.
OpenSSL is used by many major companies and some vendors have already started informing their customers about impact. Cybersecurity firm Palo Alto Networks has not identified any products that use OpenSSL 3.0, but the company is waiting for more information to become available. Trend Micro is also aware of potential impact on its products, but says more details are needed for it to make an assessment.
Akamai has conducted an analysis of some managed networks and found that roughly 50% of monitored environments had at least one device with at least one process that depends on a vulnerable version of OpenSSL.
Attack surface management and web search platform provider Censys reported that 1.7 million unique hosts have one or more services broadcasting that they use OpenSSL, but only 0.4% of them, representing 7,000 hosts, run version 3.0.0 or newer.
[ READ: Evolution of OpenSSL Security After Heartbleed ]
Eric Byres, CISA advisor and CTO of ICS/OT software security firm aDolus Technology, believes the ICS/OT world will likely not be impacted much by the vulnerability.
“We inspected over 47 million OT software and firmware packages and didn’t find a single shipping product that used OpenSSL V3. This is one case where the OT community’s incredibly slow upgrade cycle has actually paid dividends,” Byres said.
If the initial severity rating had remained unchanged, CVE-2022-3602 would have been the first critical vulnerability patched in OpenSSL since September 2016, and only the second bug to be officially assigned a ‘critical’ severity rating.
The OpenSSL Project started assigning severity ratings to vulnerabilities in 2014, when the notorious Heartbleed vulnerability came to light.
OpenSSL security has evolved a great deal since the disclosure of Heartbleed. Roughly a dozen high-severity issues were discovered between 2014 and 2017. No other high-severity vulnerabilities were found until 2020, when two issues were assigned this rating. Three high-severity flaws were found in 2021 and two in 2022.
The OpenSSL Project also released version 1.1.1s on Tuesday, but it does not contain any security fixes.
Related: Three New Vulnerabilities Patched in OpenSSL
Related: OpenSSL Vulnerability Can Be Exploited to Change Application Data
Related: High-Severity DoS Vulnerability Patched in OpenSSL
Related: OpenSSL Patches Remote Code Execution Vulnerability
