The team behind the widely used open source cryptographic library OpenSSL has patched two vulnerabilities in the service that it had previously taken the somewhat unusual step of pre-warning security teams about.
OpenSSL issued an advisory towards the end of October, saying it was preparing to patch a critical vulnerability – which would have been the first critical vulnerability disclosed in the library since Heartbleed.
Memories of Heartbleed led many to suspect an issue of similar import, but in the event, the disclosure passed off without causing widespread panic, and the initial critical status of the vulnerability was downgraded to high.
The update from OpenSSL 3.0.6 to OpenSSL 3.0.7 fixes two distinct buffer overflow vulnerabilities in Punycode decoding functions. These vulnerabilities are tracked as CVE-2022-3602 and CVE-2022-3786 respectively.
CVE-2022-3602 allows for a buffer overflow to be triggered during the parsing of an X.509 transport layer security (TLS) certificate after it is validated. This is caused by how Punycode is processed when checking certificates.
It can be exploited if an attacker can successfully craft a malicious email address to overflow four attacker-controlled bytes on the stack so an attacker must, therefore, have access to a trusted certificate to carry out a successful attack. Successfully exploited, it can lead to a crash causing denial of service and potentially to remote code execution (RCE).
CVE-2022-3786 differs slightly in that an attacker can only exploit it by crafting a malicious email address to overflow an arbitrary number of bytes that contain the period character. Successfully exploited, it can lead to a crash causing denial of service.
Yotam Perkal, director of vulnerability research at Rezilion, a specialist in software vulnerability remediation, said: “Taking all factors into account, it appears that exploitation of these vulnerabilities in the wild to achieve code execution is not highly likely. That said, exploitation is possible and hence it is advised to identify and patch vulnerable assets as soon as possible.”
Rapid7 research director Tod Beardsley added: “This OpenSSL vulnerability disclosures – and fixes – are, thankfully, not nearly as bad as all the speculation would have led us to believe.
“Vendors and operators should update their dependencies on OpenSSL to 3.0.7 when it’s practical to do so, respecting normal change control procedures and taking into account the specific risk profile for those organisations. For most people, this is not actually the emergency situation we were all expecting.”
Those that should be fast-tracking the update will most likely be those running OpenSSL implementations that have been configured for mutual authentication – where both client and server provide OpenSSL-provided certificates for authentication, Beardsley explained.
Cycode lead security researcher Alex Ilgayev said that despite the downgrade, there would be many organisations that should still treat these vulnerabilities as critical. “OpenSSL cites the use of stack overflow protections in modern software as a reason for the downgrade. Yet, many critical applications are not modern, such as those that run ATMs, utilities and other critical infrastructure,” he said.
Ilgayev explained that ultimately, the biggest takeaway from this incident for security pros is the need to keep comprehensive and maintained software bill of materials (SBOMs). “The OpenSSL 3.0.7 patch demonstrates both of these points because of OpenSSL’s ubiquity,” he said.
“Organisations without SBOMs have been scrambling to identify vulnerable OpenSSL usage since last week’s announcement. This is a prioritisation issue that most organisations would seemingly be equipped to solve. However, getting cross-functional buy-in to prioritise anything that is not immediately urgent remains a challenge for most application security teams.”
But security pros would do well to consider going beyond SBOMs to consider a pipeline bill of material (PBOM) approach, since OpenSSL’s ubiquity means it is widely used not just in an application’s source code but in the infrastructure used to build and deliver it, said Ilgayev.
PBOMs extend the SBOM concept to better reflect how dependencies are used today, accounting for third-party code that could lead to a breach even if it’s not present in the application itself, and for where dependencies are actually deployed in runtime environments.
“We should treat this exercise seriously to poke holes and find weaknesses in our SBOMs and PBOMs as recent history – Heartbleed, Struts, Jackson-databind, LodDash Log4Shell, Log4Text, and so on – demonstrates there’s always another major dependency just over the horizon,” said Ilgayev.
