OpenSSL 3.0.5 awaits release to fix potential worse-than-Heartbleed flaw

Though severity up for debate, and limited chips affected, broken tests hold back previous patch from distribution


Updated 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 ®.

Updated to add on July 5

OpenSSL 3.0.5 has been released to fix the above issue (CVE-2022-2274) with Intel processors and AVX512.

"SSL/TLS servers or other servers using 2048 bit RSA private keys running on machines supporting AVX512IFMA instructions of the X86_64 architecture are affected by this issue," an advisory dated today disclosed.

"Note that on a vulnerable machine, proper testing of OpenSSL would fail and should be noticed before deployment."

Also included in this release, and version 1.1.1q, is a fix for CVE-2022-2097: this is a programming flaw that manifests on 32-bit x86 processors, and causes not all data to be encrypted when using AES OCB mode, allowing it to potentially leak.

"AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised implementation will not encrypt the entirety of the data under some circumstances," the advisory reads.

"Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected."

Broader topics


Other stories you might like

Biting the hand that feeds IT © 1998–2022