reader comments
19 with 17 posters participating
An OpenSSL vulnerability once signaled as the first critical-level patch since the Internet-reshaping Heartbleed bug has just been patched. It ultimately arrived as a “high” security fix for a buffer overflow, one that affects all OpenSSL 3.x installations, but is unlikely to lead to remote code execution.
OpenSSL version 3.0.7 was announced last week as a critical security fix release. The specific vulnerabilities (now CVE-2022-37786 and CVE-2022-3602) had been largely unknown until today, but analysts and businesses in the web security field hinted there could be notable problems and maintenance pain. Some Linux distributions, including Fedora, held up releases until the patch was available. Distribution giant Akamai noted before the patch that half of their monitored networks had at least one machine with a vulnerable OpenSSL 3.x instance, and among those networks, between 0.2 and 33 percent of machines were vulnerable.
But the specific vulnerabilities—limited-circumstance, client-side overflows that are mitigated by the stack layout on most modern platforms—are now patched, and rated as “High.” And with OpenSSL 1.1.1 still in its long-term support phase, OpenSSL 3.x is not nearly as widespread.
Malware expert Marcus Hutchins points to an OpenSSL commit on GitHub that details the code issues: “fixed two buffer overflows in puny code decoding functions.” A malicious email address, verified within an X.509 certificate, could overflow bytes on a stack, resulting in a crash or potentially remote code execution, depending on the platform and configuration.
absurdity) of Heartbleed won’t likely follow. VPNs that utilize OpenSSL 3.x could be affected, for example, and languages like Node.js. Cybersecurity expert Kevin Beaumont points out that the stack overflow protections in most Linux distributions’ default configurations should prevent code execution.
What changed between the critical-level announcement and high-level release? OpenSSL’s security team writes in a blog post that in roughly a week’s time, organizations tested and provided feedback. On some Linux distributions, the 4-byte overflow possible with one attack overwrote an adjacent buffer not yet used, and so could not crash a system or execute code. The other vulnerability only allowed an attacker to set the length of an overflow, not the content.
So while crashes are still possible, and some stacks could be arranged in ways that make remote code execution possible, it’s not likely or easy, which downgrades the vulnerabilities to “high.” Users of any 3.x OpenSSL implementation, however, should patch as soon as possible. And everybody should be looking out for software and OS updates that may patch these issues in various subsystems.
Monitoring service Datadog, in a good summary of the issue, notes that its security research team was able to crash a Windows deployment using an OpenSSL 3.x version in a proof of concept. And while Linux deployments are not likely exploitable, “an exploit crafted for Linux deployments” could still emerge.
The National Cyber Security Centrum of the Netherlands (NCSL-NL) has a running list of vulnerable software to the OpenSSL 3.x exploit. Numerous popular Linux distributions, virtualization platforms, and other tools are listed as either vulnerable or under investigation.
