The vulnerability in OpenSSL that forced the project’s leaders to issue a security patch on Tuesday isn’t as bad as initially feared, with the hole’s severity shifted from “critical” to “high.”
Still, experts say infosec leaders need to take it seriously.
OpenSSL 3.07 fixes a buffer overrun vulnerability in version 3.0 that can be triggered in X.509 certificate verification.
It looks “not bad,” Johannes Ullrich, director of research at the SANS Institute, wrote in a blog. “Exploitation seems to be unlikely given the requirement for a valid signature from a trusted certificate authority. The remote code execution is only likely for a malformed Punycode email address. Patch this one as updated packages become available, but you can stand down from [worrying it’s as big as] ‘Heartbleed status.'”
Most organizations should ensure there is an inventory of where OpenSSL is used and what versions, wrote Jorge Orchilles, a SANS principal instructor and chief technology officer at Scythe. For OpenSSL 3.x solutions, see where and how to apply the patch, he said. Then focus on understanding the implementation of the solutions using OpenSSL 3.x that cannot be patched yet and see if there is a possibility of those implementations being exploitable.
The update fixes two similar issues, CVE-2022-3786 and CVE-2022-3602. Both create buffer overruns that can be triggered in X.509 certificate verification, specifically in name constraint checking. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the ‘.’ character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). 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.
Moses Frost, a SANS instructor, wrote that many operating system vendors apparently say there are memory and compiler protections that would make reaching this bug for true exploitability harder than thought. “There is, however, a chance that OpenSSL 3.0 is in use in network gear such as firewalls, VPNs, switches, and routers,” he added. “Most of these devices do not offer memory protections as they can’t afford to spend the computational cost of doing so. The only saving grace(s) is that the vendor may not have moved to OpenSSL 3.0 yet, and the customers may not have upgraded to software with the vulnerability. The only true way to tell is to wait for vendor disclosures.”
Patching this new OpenSSL vulnerability is just the start, said Kevin Bocek, vice-president of security strategy and threat Intelligence at Venafi, as it demonstrates how machine identities can be broken, allowing threat actors to masquerade as trusted services. “Whether we’re running in the cloud in Azure, using Kubernetes in Amazon AWS, or using Apache in your data center, the entire digital business requires safe authentication of machine identities,” he said. “The vulnerabilities in OpenSSL show the impact of poor machine identity management – specifically authenticating machine identities – opening the door to attackers.”
Yotam Perkal, director of vulnerability research at Rezilion, noted that version 3.0 of OpenSSL was only released a year ago. In IT terms, he argued, it is considered a new library, so not many software projects and applications have migrated to use it. That makes it relatively rare to find in production systems.
Still, he said, a Shodan scan suggests there are currently nearly 16,000 publicly accessible servers worldwide running potentially vulnerable versions of OpenSSL 3.x. Close to 240,000 servers are still vulnerable to the Heartbleed vulnerability, eight years after its initial discovery, he added.
SecurityScorecard said an October 28th query of its scan data to identify specific products with OpenSSL 3.x returned 116 results. Within these results, IP cameras were heavily represented: only five of the 116 were for products other than cameras.
The new OpenSSL vulnerability does not affect the issuance or use of certificates, said Tim Callan, chief compliance officer at Sectigo, so IT administrators don’t have to revoke or reissue certificates based on this flaw. This “straightforward buffer overflow vulnerability” leaves any organization using an unpatched version of OpenSSL 3.0 subject to breach, he added. “Now that this defect is widely known, we should expect attackers to begin exploiting it. Anyone on OpenSSL 3.0 should deploy the patch immediately.”
The original critical rating sparked fear this would be the next Heartbleed, noted Philippe Laulheret, a senior security researcher at Trellix. That’s not the case. Heartbleed, he said, was easy to exploit and would leak private server information, while these two bugs are memory corruption bugs whose impact is heavily lessened by modern OS and compiler security mitigations. “While it’s impossible to rule out the risk of future exploitation, the constraints to make this happen are complex enough that it makes such a thing less likely, and no more probable or dangerous than any other run-of-the-mill memory corruption vulnerability affecting online services.”
Exploiting this vulnerability requires quite a bit of set up and a number of factors to fall into place before it could be leveraged, said Victor Wieczorek, VP of application security, threat and attack simulation at GuidePoint Security.” Organizations should perform analysis to see if they are impacted, although there are relatively limited affected systems, as the attack primarily impacts the client-side, not the server. Technologies like SCA (software composition analysis) tools can help organizations identify where these components are, so they can create an inventory and then a plan for remediation based on risk.”
The fact that this is only the second critical vulnerability in OpenSSL in the better part of a decade reinforces the statement that open-source code is at least as secure as proprietary, closed-source code, said Dan Lorenc, CEO at Chainguard. “This vulnerability will likely lead to many discussions around the perceived unsustainability and insecurity of open source, but the facts remain that major, well-funded vendors see bugs like this at a much higher rate. Instead of debating the merits of open source, we should instead focus on building secure software that has the tooling necessary to make remediation faster and more seamless by rooting it in secure by default measures.”
