Patching the CentOS 8 Encryption Bug is Urgent – What Are Your Plans?

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^[1]
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^[2], the newly discovered
vulnerability in LUKS encryption, and to discuss your options for
mitigating it.

Wait, what is LUKS?

So what is LUKS^[3]? 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^[4], 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^[5] 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^[6], and specifically
Extended Lifecycle Support. It’s a solid way to obtain ongoing
protection against new CVEs that affect CentOS 8^[7]
– buying you time to migrate to another OS.