The latest version of OpenSSL v3, a widely used open source library for secure networks using the Transport Layer Security (TLS) protocol, contains a memory corruption vulnerability that compromises x64 systems with Intel’s Advanced Vector Extensions 512 (AVX512).
OpenSSL 3.0.4 was released on June 21st to fix a command injection vulnerability (CVE-2022-2068) that was not fully fixed with a previous patch (CVE-2022-1292).
But this version itself needs further repairs. OpenSSL 3.0.4 “is vulnerable to remote memory corruption, which an attacker can trivially trigger,” according to security researcher Guido Vranken. Imagine that two devices establish a secure connection between each other using OpenSSL, and this flaw is exploited to run arbitrary malicious code on one of them.
Vranken said that if this flaw can be exploited remotely – and it’s not certain it can – it could be more serious than Heartbleed, at least from a purely technical perspective.
However, Vranken notes several mitigating factors, including the continued use of the library’s 1.1.1 tree instead of the v3 tree; the fork of libssl into LibreSSL and BoringSSL; the short time that 3.0.4 was available; and the fact that the bug 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 haven’t rolled out OpenSSL 3.0.4 yet due to this bug and a test build failure. So they contain OpenSSL 3.0.3 with its command injection bug.
In the GitHub Issues thread discussing the bug, Tomáš Mráz, a software engineer at the OpenSSL Foundation, argues that the bug shouldn’t be classified as a security vulnerability.
“I don’t think this is a security vulnerability,” he said. “It’s just serious bug-making [the] 3.0.4 release not usable on AVX512 capable machines.”
Xi Ruoyao, a graduate student at Xidian University, also said he disagrees with the policy of labeling every heap buffer overflow as a security flaw. Vim, he said, started doing this this year, and the result has been about ten “high severity” Vim CVEs each month with no proof-of-concept exploit code.
“I think we shouldn’t mark a bug as a ‘vulnerability’ unless we have evidence that it can (or at least could) be exploited,” he wrote, adding that 3.0.5 is still as fast as possible should be published because it is very intense.
However, Alex Gaynor, a software resilience engineer at US Digital Service, claims the opposite.
“I’m not sure I understand why it’s not a security vulnerability,” Gaynor replied. “It’s a heap 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 the fix to be released quickly. “I think this issue ranks as CRITICAL within the OpenSSL vulnerability severity policy and makes it virtually impossible for users to upgrade to 3.0.4 to get the security fixes,” he ® said.
https://www.theregister.com/2022/06/27/openssl_304_memory_corruption_bug/ OpenSSL 3.0.5 awaiting release to fix potential security vulnerabilities • The Register