Bug 2032401 (CVE-2021-4122)

Summary: CVE-2021-4122 cryptsetup: disable encryption via header rewrite
Product: [Other] Security Response Reporter: Cedric Buissart <cbuissar>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: agk, bdettelb, caswilli, dhalasz, fjansen, gmazyland, jbrassow, jburrell, jnakfour, jwong, kaycoth, lvm-team, micjohns, mvanderw, okozina, prajnoha, psegedy, security-response-team, sthirugn, tcarlin, tkasparek, tsasak, vkrizan, vkumar, vmugicag
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: cryptsetup 2.4.3, cryptsetup 2.3.7 Doc Type: If docs needed, set a value
Doc Text:
It was found that a specially crafted LUKS header could trick cryptsetup into disabling encryption during the recovery of the device. An attacker with physical access to the medium, such as a flash disk, could use this flaw to force a user into permanently disabling the encryption layer of that medium.
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-02-01 22:02:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2031859, 2032782, 2036906, 2040194    
Bug Blocks: 2032191    

Description Cedric Buissart 2021-12-14 12:33:49 UTC
There is a multi-step attack on LUKS2 format by orchestrating LUKS2 reencryption metadata in existing LUKS2 header. 

An attacker is able to trigger permanent data decryption (ciphertext->plaintext transformation) on part of data device on next LUKS2 device activation. Attacker does _not_ have to know passphrase or decrypted volume encryption key.

An attacker who can temporarily get physical access to an encrypted device (such as a flash drive encrypted with the LUKS2 format), could use this flaw in such a scenario :
- secretly get the device and modify it with specially crafted headers
- on subsequent decryption by a regular user, the code would "recover" the data, incidentally rewriting part of it in plain text
- the attacker would then need to get access to the device again, in order to read the plaintext data
- the attacker may optionally modify the plaintext, and/or modify again the header such that it would get re-encrypted again the next time the device is open. This would affect the integrity of the data and make the attack mostly silent (almost no trace of the attack on the disk)

cryptsetup versions older than 2.2.0 are not affected by this, because they do not support online LUKS2 reencryption.

Comment 8 Cedric Buissart 2022-01-13 08:52:34 UTC
Created cryptsetup tracking bugs for this issue:

Affects: fedora-all [bug 2040194]

Comment 10 errata-xmlrpc 2022-02-01 21:03:13 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2022:0370 https://access.redhat.com/errata/RHSA-2022:0370

Comment 11 Product Security DevOps Team 2022-02-01 22:02:30 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2021-4122