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.
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 installations.
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.
By Eduard Kovacs on Tue, 01 Nov 2022 16:43:06 +0000
Original link