The OpenSSL vulnerability was once marked as the first critical-level fix since the Internet-altering Heartbleed bug was just fixed. It eventually appeared as a “high”security fix for a buffer overflow that affects all OpenSSL 3.x installations, but is unlikely to result in remote code execution.
OpenSSL version 3.0.7 was announced last week as a critical security patch. The specific vulnerabilities (now CVE-2022-37786 and CVE-2022-3602) were largely unknown until today, but web security analysts and companies have hinted that there may be noticeable issues and maintenance issues. Some Linux distributions, including Fedora, have delayed releases until a patch is released. Distribution giant Akamai noted before the patch that half of their monitored networks had at least one machine with a vulnerable instance of OpenSSL 3.x, and among those networks between 0.2 and 33 percent of the machines were vulnerable.
But specific vulnerabilities – limited circumstances, client-side overflows, which are mitigated by stack layout on most modern platforms – have now been patched and rated “high”. And because OpenSSL 1.1.1 is still in long-term support, OpenSSL 3.x isn’t as widespread.
Malware expert Markus Hutchins points to an OpenSSL commit on GitHub that details the issues with the code: “fixed two buffer overflows in code decoding functions”. A malicious email address validated with an X.509 certificate can cause a byte overflow on the stack, leading to a crash or potentially remote code execution, depending on the platform and configuration.
But this vulnerability mostly affects clients, not servers, so an internet security reset (and absurdity) like Heartbleed is unlikely to follow. For example, VPNs using OpenSSL 3.x and languages such as Node.js may be affected. Cybersecurity expert Kevin Beaumont points out that stack overflow protection in the default configurations of most Linux distributions should prevent code from executing.
What has changed between the critical announcement and the high level release? The OpenSSL security team writes on their blog that after about a week, organizations tested and provided feedback. On some Linux distributions, a 4-byte overflow possible in a single attack would overwrite an adjacent buffer that was not yet in use, and therefore could not crash the system or cause code to execute. Another vulnerability allowed an attacker to set only the length of the overflow, but not its content.
So while crashes are still possible, and some stacks can be arranged to allow remote code execution, this is unlikely or easy, reducing the vulnerability to “high”. However, users of any implementation of OpenSSL version 3.x should install the patch as soon as possible. And everyone should keep an eye out for software and OS updates that can fix these issues in various subsystems.
Monitoring service Datadog, in a good statement of the problem, notes that its security research team was able to fail a Windows deployment using OpenSSL 3.x version as a proof of concept. And while Linux deployments are unlikely to be exploitable, an “exploit built for Linux deployments”could still emerge.
The National Cyber Security Center of the Netherlands (NCSL-NL) has a current list of software vulnerable to the OpenSSL 3.x exploit. Numerous popular Linux distributions, virtualization platforms, and other tools are listed as vulnerable or under investigation.