There are three things you can be sure of in life: death, taxes – and new CVEs. For organizations that rely on CentOS 8, the inevitable has now happened, and it didn’t take long. Just two weeks after reaching the official end of life, something broke spectacularly, leaving CentOS 8 users at major risk of a severe attack – and with no support from CentOS.
You’d think that this issue no longer affects a significant number of organizations because by now, companies would have migrated away from CentOS 8 to an OS that is actively supported by vendors. After all, vendor support is critical for security and compliance.
But as it always is with these things, you can count on the fact that a big chunk of CentOS 8 users are soldiering on with an unsupported OS, despite being aware of the risks. With that risk now crystallizing we’re using this article to examine CVE-2021-4122, the newly discovered vulnerability in LUKS encryption, and to discuss your options for mitigating it.
Wait, what is LUKS?
So what is LUKS? LUKS is Linux Unified Key Setup. It’s a Linux-powered system that supports full disk encryption. This is a recommended option in “best practices” guidebooks as a system hardening solution for IT security teams.
How does LUKS work? You can make a partition only accessible during system deployment. the data within it is only understandable – with a user-supplied password. LUKS is quite complex and many security systems interact with LUKS, but a comprehensive LUKS guide is not the goal for this article.
Having a fully encrypted disk (block device in Linux “speak”) ensures that the data is safe from prying eyes even when at rest, meaning that an attacker that steals a laptop, for example, is still unable to view the confidential data contained in it.
You can increase security further by linking a particular block device to a certain computer via TPM (Trusted Platform Modul). That adds another hurdle for an attacker, making it harder to physically pull encrypted data from a machine and plug it into a high-performance system with the goal of brute-forcing access to the data. Though, as always, how likely that is to succeed depends on computing power, selected encryption algorithm, and just sheer luck.
Overall LUKS offers excellent security and is used to protect systems in a wide range of organisations.
Understanding the LUKS flaw
CVE-2021-4122 was assigned late last year, but a full understanding of the security risks around LUKS has only recently emerged. As it turns out it is possible to, at least partially, decrypt a LUKS-encrypted disk and access the data on it without owning the password used to configure encryption.
A key LUKS function allows you to modify the key used to decrypt any device on-the-fly. You would do this, for example, for scheduled key rotations in high security environments.
This on-the-fly re-encryption feature means that the device remains available during the key change process. This is called online re-encryption. It allows you to securely reencrypt your disk using a new key even if it’s offline and active.
This is how a vulnerability was discovered. This operation can be performed even if the password is not available to you – assuming you are able to remember it. Even without a password, you can request a re-encryption.
Exploiting the flaw, this process would then appear to be aborted and some of the data would be made available unencrypted. The device does not exhibit any unusual behavior at all, and it is easy to see an attacker performing the attack by simply looking at its status.
Sysadmins should upgrade cryptsetup (the package that supports LUKS) on every system under their control as this vulnerability could lead to information disclosure.
Ok, so I’ll just patch and move on…?
Exactly. This is the first thing every system administrator must do for their systems: replace the affected package. But for some sysadmins this will be easier said than done. Which sysadmins will have a hard time? You guessed right – those still reliant on CentOS 8.
Most vendors had early warning of the bug and are already providing updated packages for their distros. And just the same with Red Hat, which backs CentOS. But, with CentOS 8 now no longer officially supported, a CentOS 8 patch for the LUKS flaw is not going to appear.
For CentOS 8 users things are therefore quite bleak. Unpatched systems are vulnerable to data theft due to a published, widely known flaw. This is an extremely serious problem and you must ensure that your system has the most current patched version of the affected package.
Doing anything is not an option when sensitive data is at stake. Essentially, your confidential data cannot be made public if it is at risk. You are relying upon LUKS to protect your data.
Your patching options if you’re still on CentOS 8
There are two paths available to sysadmins relying on affected Linux systems operating past their end-of-life. One option is to download the upstream project source and to compile it locally, creating a replacement system package. Another option is to get extended support from a vendor who will give you the patches that are no longer available by the original vendor.
The build-it locally approach comes with its drawbacks. The first is that the source code of the original project does not allow for specific distributions. Each distribution or family of distributions all have their own quirks. The RHEL family, which includes CentOS, will have these quirks too.
That includes things like binary locations, service start configurations, settings, and so on. Your local team will have to manually adjust these. Whether your local IT team has the necessary expertise is a different question. Similarly, with tech teams generally under pressure to get things done, there is a risk that your DIY patching effort is delayed. Also, on the LUKS project page itself, there is this ominous “Please always prefer distro specific build tools to manually configuring cryptsetup”.
Another option is to consider extended support vendors. They are reliable, affordable and can be a more cost-effective solution. TuxCare’s Extended Lifecycle Support service does just that. TuxCare delivers high quality patches for end of life distributions such as CentOS 8 and does so on time.
What’s more you get full support for patches too. Deployment is simple, you deploy TuxCare patches just as easily as vendor-supported patches.
You must act – now
If you decide not to go for external support, you must nonetheless do something right now to protect your systems against the new vulnerability. You could decide to bite the bullet and compile cryptsetup and its dependencies locally, and perform the deployment across all your systems.
But it’s definitely not the last CVE to come out that affects CentOS 8. To give you some idea of the scope of what we’re talking about: even today there are still vulnerabilities coming out that affect CentOS 6 systems. How viable is it in the long run to keep dealing with a continuous stream of CVEs affecting CentOS 8?
You may be running CentOS 8 at this time because you were prevented from migrating to an alternative for one reason or another. It could be compatibility, support, or any one of multiple reasons.
Vulnerabilities won’t stop at EOL date, so make life easier for your IT teams, more secure for your security professionals, and meet compliance requirements around patching for your business – check out TuxCare’s family of services, and specifically Extended Lifecycle Support. It’s a solid way to obtain ongoing protection against new CVEs that affect CentOS 8 – buying you time to migrate to another OS.
