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 stands for Linux Unified Key Setup and is a mechanism used in Linux-powered systems to support, amongst other things, full disk encryption. It is recommended in many "best practice" guides as an essential system hardening option for security-minded IT teams.

How does LUKS work? Well, during system deployment, you can create a partition that is only readable – i.e. 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 further build on security by tying a specific block device to a specific computer through TPM (Trusted Platform Module). 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 provides excellent protection and for that reason, it's frequently relied on to secure systems across a variety of organizations.

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 feature is the ability to change, on the fly, the key that is used to encrypt a given device. 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. It's called "online re-encryption" – which refers to the ability to re-encrypt a disk with a different key while it is online and in active use.

It's within this process that a vulnerability was identified. It turns out that if you know what you're doing you can perform this operation without owning the original, current, password. 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. At no point does the device experience any anomalous behavior, so it would be hard to spot an attacker doing the operation just by looking at the block device status.

Sysadmins are being strongly advised to upgrade cryptsetup, the package supporting LUKS, on all systems under their control, as the vulnerability can lead to information disclosure.

Ok, so I'll just patch and move on…?

Exactly. That is what every single system administrator should do on their systems – replacing 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. It is a serious situation and one way or another you should deploy up-to-date patched versions of the affected package.

Doing nothing is not an option when confidential data is at risk. And, essentially, all your data is confidential and not for public disclosure (otherwise it would already have been made public), and you're relying on a full disk encryption solution like LUKS precisely to avoid disclosure.

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. The other option is to sign with an extended support vendor that will provide the patches no longer released by the original vendor.

The build-it-locally approach has drawbacks. First, the original project source code does not make any special allowances for a specific distribution. 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".

Your alternative is to think about extended support vendors as a reliable, cost effective and easier approach to addressing this issue. 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.