The latest version of OpenSSL v3, a widely used open-source library for secure networking using the Transport Layer Security (TLS) protocol, contains a memory corruption vulnerability that imperils x64 systems with Intel’s Advanced Vector Extensions 512 (AVX512).
OpenSSL 3.0.4 was released on June 21 to address a command-injection vulnerability (CVE-2022-2068) that was not fully addressed with a previous patch (CVE-2022-1292).
But this release itself needs further fixing. OpenSSL 3.0.4 “is susceptible to remote memory corruption which can be triggered trivially by an attacker,” according to security researcher Guido Vranken. We’re imagining two devices establishing a secure connection between themselves using OpenSSL and this flaw being exploited to run arbitrary malicious code on one of them.
Vranken said that if this bug can be exploited remotely – and it’s not certain it can be – it could be more severe than Heartbleed, at least from a purely technical point of view.
However, Vranken notes several mitigating factors, including the continued use of the 1.1.1 tree of the library rather than v3 tree; the fork of libssl into LibreSSL and BoringSSL; the short amount of time 3.0.4 has been available; and the fact that the error only affects x64 with AVX512 – available on certain Intel chips released between 2016 and early 2022.
Intel this year began disabling AVX512 support on Alder Lake, its 12th Gen Intel Core processors.
The bug, an AVX512-specific buffer overflow, was reported six days ago. It has been fixed, but OpenSSL 3.0.5 has not yet been released.
Meanwhile, Linux distributions like Gentoo have not yet rolled out OpenSSL 3.0.4 as a result of this bug and a test build failure bug. So they include OpenSSL 3.0.3, with its command injection flaw.
In the GitHub Issues thread discussing the bug, Tomáš Mráz, software developer at the OpenSSL Foundation, argues the bug shouldn’t be classified as a security vulnerability.
“I do not think this is a security vulnerability,” he said. “It is just a serious bug making [the] 3.0.4 release unusable on AVX512 capable machines.”
Xi Ruoyao, a PhD student at Xidian University, also said he disagreed with the policy of calling every heap buffer overflow a security flaw. Vim, he said, started doing so this year and the result has been something like ten “high severity” vim CVEs every month without any proof-of-concept exploit code.
“I think we shouldn’t mark a bug as ‘security vulnerability’ unless we have some evidence showing it can (or at least, may) be exploited,” he wrote, adding that nonetheless 3.0.5 should be released as soon as possible because it’s very severe.
Alex Gaynor, software resilience engineer with the US Digital Service, however, argues to the contrary.
“I’m not sure I understand how it’s not a security vulnerability,” responded Gaynor. “It’s a heap buffer overflow that’s triggerable by things like RSA signatures, which can easily happen in remote contexts (e.g. a TLS handshake).”
Gaynor urged releasing the fix quickly. “I think this issue qualifies as a CRITICAL within OpenSSL’s vulnerability severity policy, and it makes it effectively impossible for users to upgrade to 3.0.4 to obtain its security fixes,” he said ®.