A week after warning the infosec community of a critical vulnerability in OpenSSL, developer OpenSSL Project has released a patch as scheduled. Turns out, the vulnerability wasn’t all that critical, though it remains important to patch.
On October 25, the OpenSSL Project announced that one of the two vulnerabilities discovered in the OpenSSL library/toolkit was a critical one, sending the tech community into a tizzy. However, the CVEs and patch releases indicate that the vulnerability (CVE-2022-3602) is far from being as severe as the only other critical vulnerability discovered in OpenSSL since 2014’s Heartbleed Bug.
Nevertheless, both CVE-2022-3602Opens a new window and CVE-2022-3786Opens a new window are still termed high-severity flaws with a CVSS score of 8.8, just 0.2 points lower than what they would need to be termed critical. Patches for the two flaws, residing in OpenSSL version 3.0.0 through 3.0.6, are now available to download.
OpenSSL Project describes both as buffer overrun vulnerabilities with CVE-2022-3602 (initially thought to be critical), making the vulnerable machine susceptible to denial of service or potentially remote code execution. Gareth Lindahl-Wise, the chief security advisor at Tiberium, told Spiceworks, “While not being currently exploited, the RCE potential should be taken seriously and acted upon.â€
On the other hand, exploitation of CVE-2022-3786, which like CVE-2022-3602, is triggered in X.509 certificate verification through a malicious email certificate, could enable the attacker to carry out a denial of service attack.
“The original bug only allows an attacker to corrupt four bytes on the stack, which limits the exploitability of the hole, while the second bug allows an unlimited amount of stack overflow, but apparently only of the “dot†character (ASCII 46, or 0x2E) repeated over and over again,†noted Paul Ducklin, principal research scientist at Sophos.
CVE-2022-3602 was discovered on October 17 by cybersecurity researcher Polar Bear while CVE-2022-3786 the next day, on October 18 by Viktor Dukhovni while researching CVE-2022-3602. CVE-2022-3602’s October 25 notification led the cybersecurity community to assess their implementations of the ubiquitous open-source SSL and TLS security protocol library.
“I think that by announcing the new critical OpenSSL vulnerability several days in advance of revealing the details, the team is enabling organizations to prepare effectively,†Jeff Williams, co-founder and CTO at Contrast Security, told Spiceworks. “When the new version is released, attackers will reverse engineer the update and create exploits. Attacks on this new vulnerability will start almost immediately thereafter. So, this advance warning is useful and welcome.â€
OpenSSL is, after all, used for encryption and server authentication over the Internet for operating systems (Windows, macOS, and Linux), HTTPS websites and the underlying servers and email servers.
See More: Mitigating Security Risks As a Hybrid Organization
Roger Grimes, a data-driven defense evangelist at KnowBe4, told Spiceworks, “The challenge is that OpenSSL is all over the place, in software, hardware, firmware, and appliances, and many of the people and organizations using it aren’t even aware they have it, much less that it needs to be updated.â€
Thankfully, the two vulnerabilities only affect OpenSSL versions 3.0.0 through 3.0.6, reducing the range of in-the-wild vulnerable implementations. “Most OpenSSL instances don’t have a process that proactively alerts people that it needs to be updated,†Grimes continued.
“In the past, previous vulnerable instances of OpenSSL numbered in the many millions for a long, long time.†This certainly held true for the Heartbleed vulnerability, which still plagues 90,000 serversOpens a new window five years after the initial disclosure, according to SentinelOne. Rezilion leveraged Shodan to assess that 240,000 serversOpens a new window are still vulnerable to Heartbleed.
So it is possible that OpenSSL Project’s notification, even if it caused mass hysteria for a week, probably helped the news reach those that would’ve otherwise ignored identifying and patching.
Censys data indicates that there are currently 7,062 hosts thatOpens a new window run OpenSSL version 3.0.x (released almost a year ago) out of 1,793,111. Rezilion said there are 16,000 publicly accessible servers runningOpens a new window OpenSSL 3.0.x.
That all said, if the stars do align, the attacker takes over the machine. So don’t ignore it. Patch it for sure. But I also wouldn’t lose any sleep over it. OpenSSL is correctly noting that the worst case is very bad. It’s just unusually unlikely that the worst case will happen
— Noted Security Wizard Pwn All The Things (@pwnallthethings) November 1, 2022Opens a new window
“The OpenSSL vulns do not look like a big deal. In most default config Linux distributions, stack overflow protections will automatically mitigate code execution,†researcher Kevin Beaumont opined. “As always, assess and proceed calmly through your usual vulnerability management process.â€
Williams explained to Spiceworks what this vulnerability management process should constitute. “First, we need to establish a continuous inventory of exactly what software we are relying on across our entire digital infrastructure,†William said. This includes any infrastructure that might be embedded with vulnerable versions of OpenSSL.
Lindahl-Wise attested to this and added, “Being able to search for specific configs or software version numbers is a critical playbook that people need to have, and have practiced. Log4j, anyone?â€
“Second,†Williams continued, “we need to enhance our ability to update our software quickly. And finally, since we know it will take some time to update (particularly when software is controlled by third parties), we need to have an infrastructure that allows us to very quickly deploy alternative protections that detect and prevent exploits.â€
The best way to mitigate CVE-2022-3602 and CVE-2022-3786 would be to update OpenSSL to version 3.0.7. Martin Jartelius, CSO at Outpost24, suggested organizations prioritize internet-facing and business-critical assets that have sensitive data.
Let us know if you enjoyed reading this news on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!
Image source: Shutterstock