OpenSSL 3.0 Vulnerabilities Not Exploited in the Wild
Much-anticipated vulnerabilities in an open source cryptography library used for digital certificates aren’t as dire as feared, with the open source foundation behind the application downgrading its severity from “critical” to “high.”
The last time the OpenSSL team, which maintains an application ubiquitous in connected devices for encrypting and decrypting data as it travels across networks, announced a critical patch, it was in 2014 and the vulnerability was Heartbleed.
Security teams primed for a slog of emergency patching today instead are reacting with relief. “I don’t think we’ll be doing overtime this afternoon,” said Chester Wisniewski, Sophos principal research scientist. OpenSSL warned last Tuesday’s it would issue impending critical patch today.
Major web browsers including Google’s Chrome and the Mozilla Foundation’s Firefox stopped using OpenSSL after Heartbleed, with Google migrating to a fork it dubbed BoringSSL. Other versions of SSL appear unaffected.
Among the many mitigating factors are the vulnerabilities’ limited scope: Only OpenSSL versions 3.0 and above – not counting Tuesday’s patched version – are affected by what’s not designated as CVE-2022-3602 and CVE-2022-3786. The vulnerabilities have not been exploited in the wild and neither does there yet exist a proof of concept. OpenSSL 3 is barely a year old, narrowing the base of products needing patching.
The Dutch national cybersecurity center is maintaining a running list of applications affected and unaffected alike. Among the former is Redhat Enterprise Linux 9. The company acknowledged getting ahead of most other Linux distributions when only this past June it shipped its enterprise operating system with OpenSSL 3.
“That probably is the factor that most limits this – is just that the vast, vast majority of OpenSSL usage is on older versions,” said Boaz Gelbord, chief security officer of Akamai. The content delivery network company scanned its managed networks to find that about half of had a least one machine with one process dependent on OpenSSL 3. Of those networks, the percentage of machines with a dependence on a vulnerable OpenSSL version ranged from 0.2% to 33%.
Unlike Heartbleed, clients, and not servers, are the main worry as potential targets. The vulnerabilities depend on a malicious certificate to trigger a 4 byte buffer overflow for remote code execution or operating system crash. In many scenarios, it’s the client rather than the server that verifies the certificate.
“It appears to be there would be an almost zero quantity of servers at risk because so few of them request client certificates,” Wisniewski told Information Security Media Group.
Avesta Hojjati, head of research and development at certificate authority DigiCert, told ISMG some servers in enterprise settings might require an end-user certificate. Still, the executive rued getting up early in the morning for a commute to his Austin, Texas office, saying the trip in retrospect appeared unnecessary.
Another way of triggering vulnerabilities would be should the client continue certificate verification despite failure to construct a path to a trusted issuer – but security experts also discounted that as a widespread vulnerability. “There’s a bunch of things that have to happen for it to be exploitable,” said Gelbord.
In an afternoon blog post, OpenSSL said it initially rated remote code vulnerability CVE-2022-3602 as critical despite getting feedback from Linux testers that they couldn’t recreate the vulnerability, in some cases because the distributions had stack overflow protections.
“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,” the OpenSSL team wrote. It nonetheless downgraded the rating shortly before releasing the patch after concluding that the vulnerabilities were unlikely to be exploited in common situations.