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 compromises x64 systems with advanced vector extensions 512 (AVX512) from Intel.
OpenSSL 3.0.4 was released on June 21 to address a command injection vulnerability (CVE-2022-2068) which was not fully resolved with a previous patch (CVE-2022-1292).
But this version itself still needs to be fixed. OpenSSL 3.0.4 “is susceptible to remote memory corruption that can be trivially triggered by an attacker”, according to a security researcher Guido Vranken. We imagine two devices establishing a secure connection between them using OpenSSL and this flaw being exploited to execute arbitrary malicious code on one of them.
Vranken said that if this bug could be exploited remotely – and it’s not certain that it can – it could be more serious than Heartbleed, at least from a purely technical standpoint.
However, Vranken notes several mitigating factors, including the continued use of the 1.1.1 tree of the library rather than the v3 tree; the fork of libssl in LibreSSL and BoringSSL; the short time that 3.0.4 has been available; and the fact that the error only affects x64 with AVX512 – available on some Intel chips released between 2016 and early 2022.
Intel this year started to disable AVX512 support on Alder Lake, its 12th Gen Intel Core processors.
Meanwhile, Linux distributions like Gentoo have not yet deployed OpenSSL 3.0.4 as a result of this bug and a test build failure bug. So that they include OpenSSL 3.0.3with its command injection defect.
In the GitHub issues thread Discussing the bug, Tomáš Mráz, software developer at the OpenSSL Foundation, asserts that the bug should not be classified as a security vulnerability.
“I don’t think it’s a security breach,” he said. said. “It’s just a serious bug [the] Version 3.0.4 is unusable on AVX512 compatible machines.”
Xi Ruoyao, a doctoral student at Xidian University, also said he disagreed with the policy of calling every heap buffer overflow a security hole. Vim, he said, started doing this this year and the result was 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 a ‘security vulnerability’ unless we have evidence showing it can (or at least can) be exploited,” he wrote, adding that however, version 3.0.5 should be released as soon as possible. because it is very harsh.
Alex Gaynor, software resilience engineer at US Digital Service, argues otherwise, however.
“I’m not sure I understand how this isn’t a security flaw,” replied Gaynor. “This is a buffer overflow that can be triggered by things like RSA signatures, which can easily happen in remote contexts (e.g. a TLS handshake).”
Gaynor urged releasing the patch quickly. “I believe this issue is rated CRITICAL in the OpenSSL Vulnerability Severity Policy, and it effectively makes it impossible for users to upgrade to 3.0.4 to get its security patches,” he said. declared. said ®.