TL; DR: Flatcar is safe against recent OpenSSL vulnerabilities

With the recent OpenSSL vulnerabilities CVE-2022-3786 and CVE-2022-3602 , the Flatcar team has provided as soon as possible a batch of releases for impacted Flatcar channels (all except LTS which is not impacted). Releases have been published within one hour after the official public announcement and users were able to secure their workloads almost immediately without unexpected turbulences as the releases included only minimal changes to address the security issues.

A few hours later, we started to get some user feedback regarding the OpenSSL version displayed by the CLI:

How has this actually been fixed in the newest releases? OpenSSL still sits on 3.0.2

Source: Twitter

So I have tested stable, alpha, and beta, all three when I run openssl version are still showing an old version pre 3.0.7

Source: Github

openssl version should report 3.0.7 the version the two critical CVE’s have been fixed

Source: Github

The version returned by the CLI is 3.0.2 instead of 3.0.7 but the package version is 3.0.2-r1: this package version provides the security fixes as downstream patches compared to the previous package version 3.0.2 without the –r1 suffix. A legitimate question can be: How is Flatcar, with OpenSSL 3.0.2, safe against these vulnerabilities? To understand this, we need to take a few steps back and to understand the Flatcar build process.

Flatcar build process

Flatcar, with its inheritance from Gentoo, does build packages from sources – the build recipe is called an ebuild file. It defines the various steps involved during the preparation, the compilation, and the installation of the package: which compilation options are being used, which files are installed on the system, which kernel configuration is required for the package to work fine, etc.

As the packages are built from sources, it is easy to apply patches during the preparation of the package. Patches can be simply generated from diff or using git format-patch … command and Gentoo knows how to handle and apply patches defined in the ebuild file.

OpenSSL prenotification policy

OpenSSL tries to keep users notified of newer releases that include security fixes on the openssl-announce mailing list. For CRITICAL, HIGH, or MODERATE security fixes, OpenSSL also notifies organizations defined in the following list: distros . Flatcar is included in the list and as stated by the prenotification policy :

[…] we will also prenotify certain organisations with more details and patches

Which means that before the official announcement, Flatcar and other Linux distros were already in possession of the embargoed patches. These patches alone are not the 3.0.7 release as that includes also regular changes and features brought by usual releases.

Therefore, with the OpenSSL prenotification policy and the Flatcar build process, the Flatcar team has been able to apply these patches in release builds and to deliver on time a set of patched Flatcar releases. The 3.0.7 release was only available when the embargo was lifted in contrast to the security patches which were shared earlier. To release on time, we didn’t wait for the 3.0.7 release but applied the downstream patches. Applying security patches downstream is common and can often be found in long-term support distributions. There the goal is to take a security patch by backporting instead of updating to a newer version because that would bring the risk of breakage due to unrelated changes.

The official release 3.0.7 will follow like every other regular Flatcar package update from Alpha to Stable to ensure validation across the release channels as we did not want to introduce side effects from other features of 3.0.7 directly into the Flatcar Stable update so that users can update swiftly without any risk.

In the end, it turned out that like many other distros, Flatcar wasn’t even affected by the security issue, as can be tested with the proof-of-concept reproducer in https://github.com/colmmacc/CVE-2022-3602 .