CVE-2021-4122: cryptsetup 2.x: decryption through LUKS2 reencryption crash recovery

Has CVE-2021-4122 been flagged for a security review? Searches did not return any mention of the reencryption multi-step attack. There is an upgrade to cryptsetup available in other distributions.
This is a medium risk level, but should qualify as a ‘hole in the cheese.’

(oss-sec: CVE-2021-4122: cryptsetup 2.x: decryption through LUKS2 reencryption crash recovery)

from what i read, the method is ‘LUKS2 reencryption metadata in existing LUKS2 header’ and that mean user who detach header are not vulnerable to this.

Since there isn’t a step during installation to store the header somewhere else the default apparently is to store the header on the LUKS2 device.

The attack requires repeated access to the physical device by the
attacker.
It’s not at all clear that a detached header will protect
against the attack - if the attacker has access to the device holding
the header then they can modify the metadata as needed, and the attack
will proceed.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

IIUC*: The attack would fail if AEM/Heads is used (because the LUKS header is measured, meaning the attacker can’t add a reencryption keyslot without alerting the user), and if AEM/Heads isn’t used then why not just tamper with the boot partition to make it grab the encryption passphrase?

*Edit: Apparently the attack wouldn’t actually add a keyslot? But it does change the output of cryptsetup luksHeaderBackup (used by AEM) and cryptsetup luksDump (used by Heads), right?

2 Likes

Both valid points, which cut to the heart of it.

1 Like

Discovering all the permutations by which access to the physical drive could be accomplished is very difficult, especially in a data center.
Even with direct access to the physical drive it is correct that a detached head would make it impossible to decrypt the data and the data could still be destroyed.
The upgrade to cryptsetp-2.4.3 removes the threat addressed in the CVE.
Thanks for taking a look.

If an attacker has repeated access to the drive, then they could gain
the same access to the medium holding the header, no?
It’s true that the update addresses this threat - the question is, is it
a threat to Qubes users?

the process is

  1. attacker get access to drive (pc / laptop).
  2. attacker modify header.
  3. user need to decrypt, which decrypting the modified header.
  4. attacker need to get access again to drive to read plaintext data.

if the detach user is losing the flashdrive, i’m sure that they will copy the backup again rather than searching for the lost flashdrive.

if it’s a threat or not to qubes users, yes it is.

Again, trying to guess which scenario works for which configuration is very difficult.
The discussions in the forum seem to hover around single user configurations.
But as a major swag, one scenario could involve data centers and hot swapping.
The modification would have to occur during an initiated crash while the operator is in the reencryption extension.
The initial conditions can be set up by the attacker(s) where a coded response to operataor actions are taken and as such they will not have to be actively present to perform these actions.
Even a very low hit/miss ratio offset against the number of pertinent swaps in a datacenter will likely eventually lead to a successful atack.

The current installation of dom0 does use an affected version of cryptsetup.

The security in the use of a detached header was only a statement of fact, not intended to be a consideration in these scenarios.

The original question was only to determine if the CVE was reviewed and whether the package was to be updated.

One of the security goals here is to severely reduce the tools attackers have to compromise this system and even more to lower the chance of cascading vulnerabilities.
Apologies for protracting the intent.

Again, trying to guess which scenario works for which configuration is very difficult.

That’s because this is a Qubes forum and Qubes is a single user system.

Scenarios about attacks on machines in data centres or multi-user
systems are outwith the concerns of Qubes.

Yes, it does.
But if you do not protect your system (as detailed by RustyBird), you
are at the mercy of anyone who has access to it.
Replacing this version of cryptsetup wont change that level of
vulnerability at all.

I do not believe it is a fact in this circumstance.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

Two questions:

  1. Those who use (U)EFI or GPT also use AEM?
  2. Access to LUKS2 header garantees the ability to modify the boot partition?

This was agreeing with:

Agreed:
https://groups.google.com/g/qubes-users/c/ny_iREB5Q3U

Poor example in an attempt to further the question.
The example wasn’t useful in conveying the concern.

Can you (any one?) explain why a detached header means that the LUKS is
not vulnerable?

All it means is that the attacker would have to gain access to the
device storing the header rather than the encrypted device.
If you are unable to secure the drive, then you are probably unable
to secure the header store.

1 Like

My bad, yes it’s vulnerable. it’s just adding another layer protection, so i can’t judge by ‘assumption’.

So another, probably inadequate scenario:
A user takes a laptop in to have a cracked screen replaced. The detached LUKS2 header is stored on a USB drive kept separate from the physical drive by the user.
Can the LUKS2 partitions be decrypted by the repair shop without access to the USB drive?

most likely no (unless intelligent agency want your laptop)

reading Cryptsetup FAQ is more helpful. there’s some example of situation, worth to read.