* [dm-crypt] [ANNOUNCE] cryptsetup 2.4.3 (CVE-2021-4122 fix) @ 2022-01-13 10:05 Milan Broz 2022-01-13 18:24 ` [dm-crypt] " Christoph Anton Mitterer 0 siblings, 1 reply; 6+ messages in thread From: Milan Broz @ 2022-01-13 10:05 UTC (permalink / raw) To: dm-crypt [-- Attachment #1.1.1: Type: text/plain, Size: 5197 bytes --] The cryptsetup 2.4.3 stable release is available at https://gitlab.com/cryptsetup/cryptsetup Please note that release packages are located on kernel.org https://www.kernel.org/pub/linux/utils/cryptsetup/v2.4/ Feedback and bug reports are welcomed. Cryptsetup 2.4.3 Release Notes ============================== Stable security bug-fix release that fixes CVE-2021-4122. All users of cryptsetup 2.4.x must upgrade to this version. Changes since version 2.4.2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Fix possible attacks against data confidentiality through LUKS2 online reencryption extension crash recovery (CVE-2021-4122). An attacker can modify on-disk metadata to simulate decryption in progress with crashed (unfinished) reencryption step and persistently decrypt part of the LUKS device. This attack requires repeated physical access to the LUKS device but no knowledge of user passphrases. The decryption step is performed after a valid user activates the device with a correct passphrase and modified metadata. There are no visible warnings for the user that such recovery happened (except using the luksDump command). The attack can also be reversed afterward (simulating crashed encryption from a plaintext) with possible modification of revealed plaintext. The size of possible decrypted data depends on configured LUKS2 header size (metadata size is configurable for LUKS2). With the default parameters (16 MiB LUKS2 header) and only one allocated keyslot (512 bit key for AES-XTS), simulated decryption with checksum resilience SHA1 (20 bytes checksum for 4096-byte blocks), the maximal decrypted size can be over 3GiB. The attack is not applicable to LUKS1 format, but the attacker can update metadata in place to LUKS2 format as an additional step. For such a converted LUKS2 header, the keyslot area is limited to decrypted size (with SHA1 checksums) over 300 MiB. The issue is present in all cryptsetup releases since 2.2.0. Versions 1.x, 2.0.x, and 2.1.x are not affected, as these do not contain LUKS2 reencryption extension. The problem was caused by reusing a mechanism designed for actual reencryption operation without reassessing the security impact for new encryption and decryption operations. While the reencryption requires calculating and verifying both key digests, no digest was needed to initiate decryption recovery if the destination is plaintext (no encryption key). Also, some metadata (like encryption cipher) is not protected, and an attacker could change it. Note that LUKS2 protects visible metadata only when a random change occurs. It does not protect against intentional modification but such modification must not cause a violation of data confidentiality. The fix introduces additional digest protection of reencryption metadata. The digest is calculated from known keys and critical reencryption metadata. Now an attacker cannot create correct metadata digest without knowledge of a passphrase for used keyslots. For more details, see LUKS2 On-Disk Format Specification version 1.1.0. The former reencryption operation (without the additional digest) is no longer supported (reencryption with the digest is not backward compatible). You need to finish in-progress reencryption before updating to new packages. The alternative approach is to perform a repair command from the updated package to recalculate reencryption digest and fix metadata. The reencryption repair operation always require a user passphrase. WARNING: Devices with older reencryption in progress can be no longer activated without performing the action mentioned above. Encryption in progress can be detected by running the luksDump command (output includes reencrypt keyslot with reencryption parameters). Also, during the active reencryption, no keyslot operations are available (change of passphrases, etc.). The issue was found by Milan Broz as cryptsetup maintainer. Other changes ~~~~~~~~~~~~~ * Add configure option --disable-luks2-reencryption to completely disable LUKS2 reencryption code. When used, the libcryptsetup library can read metadata with reencryption code, but all reencryption API calls and cryptsetup reencrypt commands are disabled. Devices with online reencryption in progress cannot be activated. This option can cause some incompatibilities. Please use with care. * Improve internal metadata validation code for reencryption metadata. * Add updated documentation for LUKS2 On-Disk Format Specification version 1.1.0 (with reencryption extension description and updated metadata description). See docs/on-disk-format-luks2.pdf or online version in https://gitlab.com/cryptsetup/LUKS2-docs repository. * Fix support for bitlk (BitLocker compatible) startup key with new metadata entry introduced in Windows 11. * Fix space restriction for LUKS2 reencryption with data shift. The code required more space than was needed. [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 147 bytes --] _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* [dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix) 2022-01-13 10:05 [dm-crypt] [ANNOUNCE] cryptsetup 2.4.3 (CVE-2021-4122 fix) Milan Broz @ 2022-01-13 18:24 ` Christoph Anton Mitterer 2022-01-14 11:18 ` Ondrej Kozina 0 siblings, 1 reply; 6+ messages in thread From: Christoph Anton Mitterer @ 2022-01-13 18:24 UTC (permalink / raw) To: dm-crypt Hey. On Thu, 2022-01-13 at 11:05 +0100, Milan Broz wrote: > An attacker can modify on-disk metadata to simulate decryption in > progress with crashed (unfinished) reencryption step and > persistently > decrypt part of the LUKS device. Just for my understanding... 1) Wouldn't that then cause complete decryption? I.e. cryptsetup sees that re-encrypt (to plain text) was allegedly aborted at block XYZ... and then re-encrypts (to plain text) from there on the whole device? 2) And shouldn't that fail then next time, the device is opened? Either because it was completely transformed to plain text, while some encryption is expected... or because an attack started only e.g. at half o the blocks, but then one half is encrypted and the other not? 3) Would it also have been possible, to re-encrypt with another key? In other words, is the new key written to some extra header area... or is it rather just some new keyslot, encrypted with a passphrase, and thus that would have been (hopefully) noticed when "resuming" re-encryption, and the passphrase doesn't match (respectively the legit user cannot unlock the keylslot)? > The attack is not applicable to LUKS1 format, but the attacker can > update metadata in place to LUKS2 format as an additional step. Shouln't "all" (at least as far as possible) of the header be secured by some MAC or so, so that cryptsetup would abort before opening, when something seems fishy? Not just with respect to re-encryption, but also e.g. which header version is used, or settings like whether DISCARD shall be used (which may have some security impact)? Thanks, Chris. _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* [dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix) 2022-01-13 18:24 ` [dm-crypt] " Christoph Anton Mitterer @ 2022-01-14 11:18 ` Ondrej Kozina 2022-01-15 4:06 ` Christoph Anton Mitterer 0 siblings, 1 reply; 6+ messages in thread From: Ondrej Kozina @ 2022-01-14 11:18 UTC (permalink / raw) To: dm-crypt; +Cc: Christoph Anton Mitterer Hi Christoph, On 13. 01. 22 19:24, Christoph Anton Mitterer wrote: > Hey. > > > On Thu, 2022-01-13 at 11:05 +0100, Milan Broz wrote: >> An attacker can modify on-disk metadata to simulate decryption in >> progress with crashed (unfinished) reencryption step and >> persistently >> decrypt part of the LUKS device. > > Just for my understanding... > > 1) Wouldn't that then cause complete decryption? I.e. cryptsetup sees > that re-encrypt (to plain text) was allegedly aborted at block XYZ... > and then re-encrypts (to plain text) from there on the whole device? Not without user manual intervention. Currently, the reencryption operation can not be resumed unless user directly issue "cryptsetup reencrypt" command (applies to both fixed and vulnerable cryptsetups). And it would require user to provide proper passphrase. Since it requires user's manual input it gives user also space to verify the state of LUKS2 metadata with e.g. luksDump command before triggering the command. On the other hand, the vulnerability primarily targets LUKS2 reencryption auto-recovery feature. Auto-recovery takes place in two scenarios: a) cryptsetup repair command (again manual intervention with interactive query and passphrase prompt) b) LUKS2 device activation e.g. during system boot. Let's focus on b) a little: The LUKS2 reencryption was designed in a way that even if the operation is interrupted forcefully (system crash/power failure) the system should be able to recover from it automatically. So the recovery from reencryption crash is seamless provided user knows passphrase. In corner case, when device is small enough to fit limits disclosed in the vulnerability report (and LUKS2 spare metadata space allows it) the auto-recovery may actually finish the decryption process (in one step). > > 2) And shouldn't that fail then next time, the device is opened? Only if user willingly resumes reencryption or in corner case described above. Yes in that case the device activation would fail because there are no VK stored in remaining LUKS2 header stub. Anyway, an attacker could easily avoid this scenario but forging the LUKS2 metadata in a way that at least single sector remains encrypted. > Either because it was completely transformed to plain text, while some > encryption is expected... above or because an attack started only e.g. at > half o the blocks, but then one half is encrypted and the other not? Nope, in this case device would activate just fine, part of the device encrypted and part plaintext (multi segment device-mapper device). Otherwise we would be unable to activate partially decrypted devices due to interruption. Same applies to devices in encryption or reencryption. > > 3) Would it also have been possible, to re-encrypt with another key? In > other words, is the new key written to some extra header area... or is > it rather just some new keyslot, encrypted with a passphrase, and thus > that would have been (hopefully) noticed when "resuming" re-encryption, > and the passphrase doesn't match (respectively the legit user cannot > unlock the keylslot)? Ransomware attack is not possible provided attacker does not know valid passphrase or VK, if that's what you're asking: Yes, attacker can add new unbound LUKS2 keyslot (with key not assigned to current encrypted segment), but he does not know proper passphrase (P_OK) to one of existing keyslots (with valid VK). So the keyslot is protected by different passphrase P_X. So attacker can forge such LUKS2 metadata, add new LUKS2 keyslot but the attack itself would not trigger properly during auto-recovery or even manual cryptsetup reencrypt command. Reencryption requires all necessary VKs unlocked to properly resume or perform recovery. > > >> The attack is not applicable to LUKS1 format, but the attacker can >> update metadata in place to LUKS2 format as an additional step. > > Shouln't "all" (at least as far as possible) of the header be secured > by some MAC or so, so that cryptsetup would abort before opening, when > something seems fishy? That would not be possible with LUKS2 format, or better say with current version of API of libcryptsetup. If the whole header was to be protected by MAC it would require complete rework of API which would not be backward compatible. It would probably be LUKS3 format/library. Also, just for LUKS2 reencryption, it would completely kill the performance of the operation. During LUKS2 reencryption the json metadata area gets updated quite often (twice per single reencryption step which is typically ~100MiBs of data reencrypteed with checksum resilience mode). If we calculated authentication digest (time expensive operation) in each step twice it would not go fast. Kind regards Ondrej > > Not just with respect to re-encryption, but also e.g. which header > version is used, or settings like whether DISCARD shall be used (which > may have some security impact)? > > > Thanks, > Chris. > _______________________________________________ > dm-crypt mailing list -- dm-crypt@saout.de > To unsubscribe send an email to dm-crypt-leave@saout.de _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* [dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix) 2022-01-14 11:18 ` Ondrej Kozina @ 2022-01-15 4:06 ` Christoph Anton Mitterer 2022-01-17 11:05 ` Ondrej Kozina 0 siblings, 1 reply; 6+ messages in thread From: Christoph Anton Mitterer @ 2022-01-15 4:06 UTC (permalink / raw) To: dm-crypt On Fri, 2022-01-14 at 12:18 +0100, Ondrej Kozina wrote: > > 1) Wouldn't that then cause complete decryption? I.e. cryptsetup > > sees > > that re-encrypt (to plain text) was allegedly aborted at block > > XYZ... > > and then re-encrypts (to plain text) from there on the whole > > device? > > Not without user manual intervention. Currently, the reencryption > operation can not be resumed unless user directly issue "cryptsetup > reencrypt" command (applies to both fixed and vulnerable > cryptsetups). Then I don't understand the attack... cause if t would be only resumed if one enters a command manually, the attacked user would notice? > On the other hand, the vulnerability primarily targets LUKS2 > reencryption auto-recovery feature. Auto-recovery takes place in two > scenarios: ... > b) LUKS2 device activation e.g. during system boot. Okay that's the situation I've had meant before. > So the recovery from > reencryption crash is seamless provided user knows passphrase. And that's the point where I'd have expected the full decryption, i.e.: - an attacker messes with the headers while the device is offline - the user opens it (e.g. on next boot), doesn't notice anything - cryptsetup "continues" silently, but actually decrypts > In corner case, when device is small enough to fit limits disclosed > in > the vulnerability report (and LUKS2 spare metadata space allows it) > the > auto-recovery may actually finish the decryption process (in one > step). I think I don't understand how the spare header space affects this? I thought you'd just use that as kind of a journal? And to keep a copy of the region that is currently re-encrypted, and once that one has finished it would move on? > > or because an attack started only e.g. at > > half o the blocks, but then one half is encrypted and the other > > not? > > Nope, in this case device would activate just fine, part of the > device > encrypted and part plaintext (multi segment device-mapper device). > Otherwise we would be unable to activate partially decrypted devices > due > to interruption. Same applies to devices in encryption or > reencryption. So you keep book (in a secured way?) on which regions have been re- encrypted already and which not? I assumed it would be just some "pointer" that shows at one position from start to end, where the system currently was. > Ransomware attack is not possible provided attacker does not know > valid > passphrase or VK, if that's what you're asking: That was less about ransomware attack... cause when an attacker would have access to the offline device, he'd either compromised the system already, or has physical access... and in both cases he could also just do the attack (or simply steal the physical device). I was rather just wondering, whether during encrypting the new key is ever written to disk in an insecure way (which they keyslot, where it is encrypted, wouldn't be) > That would not be possible with LUKS2 format, or better say with > current > version of API of libcryptsetup. If the whole header was to be > protected > by MAC it would require complete rework of API which would not be > backward compatible. It would probably be LUKS3 format/library. Well... could save us from troubles some day ;-) > Also, just for LUKS2 reencryption, it would completely kill the > performance of the operation. During LUKS2 reencryption the json > metadata area gets updated quite often (twice per single reencryption > step which is typically ~100MiBs of data reencrypteed with checksum > resilience mode). If we calculated authentication digest (time > expensive > operation) in each step twice it would not go fast. That refers to the information on which regions have already been re- encrypted right? I assume, unless re-"encryption" to plain text is performed,... the clear-text never goes on disk during a "normal" re-encryption?! Thanks, Chris. _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* [dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix) 2022-01-15 4:06 ` Christoph Anton Mitterer @ 2022-01-17 11:05 ` Ondrej Kozina 2022-01-24 20:50 ` Christoph Anton Mitterer 0 siblings, 1 reply; 6+ messages in thread From: Ondrej Kozina @ 2022-01-17 11:05 UTC (permalink / raw) To: Christoph Anton Mitterer, dm-crypt Hi, On 15. 01. 22 5:06, Christoph Anton Mitterer wrote: > On Fri, 2022-01-14 at 12:18 +0100, Ondrej Kozina wrote: >>> 1) Wouldn't that then cause complete decryption? I.e. cryptsetup >>> sees >>> that re-encrypt (to plain text) was allegedly aborted at block >>> XYZ... >>> and then re-encrypts (to plain text) from there on the whole >>> device? >> >> Not without user manual intervention. Currently, the reencryption >> operation can not be resumed unless user directly issue "cryptsetup >> reencrypt" command (applies to both fixed and vulnerable >> cryptsetups). > > Then I don't understand the attack... cause if t would be only resumed > if one enters a command manually, the attacked user would notice? Sure, I can explain better. Let's stick to two different terms: I. individual reencryption step (reencryption of one of many hotzones) II. device reencryption (aka iteration of I. steps) The reencryption hotzone stored in LUKS2 metadata describes following (let's make it decryption attack example): "the data starting at offset X, Y length, describes block in transition from ciphertext to plaintext that was not finished yet". If libcryptsetup see such metadata stored in LUKS2 header, it performs auto-recovery during device activation. During auto-recovery triggered by e.g. cryptsetup luksOpen command, libcryptsetup does not perform whole decryption of device (II., it only checks last hotzone (I.) is correcly decrypted. If not it finishes the single hotzone so that it is in correct new state (plaintext) as described in LUKS2 metadata. Afterwards, the device gets activated usually as two segment DM device. Following example is device activated when decryption recovers after crash somewhere in the middle of the data device: [LUKS2 on-disk header][data: plaintext][data: ciphertext] To finish the decryption process (II.), user would have to manually issue "cryptsetup reencrypt" command again. If you want to understand the reencryption as whole better, please see my slides for the LUKS2 reencryption extension here: https://okozina.fedorapeople.org/online-disk-reencryption-with-luks2-compact.pdf, on slide 8 and later is the process described step-by-step (also, the talk recording: https://youtu.be/54vyOO8mWGg). So the attack primarily targets recovery, the single hotzone crash recovery process in activation code. To resume/finish the reencryption process (and complete all steps in II.) user would have to issue cryptsetup reencrypt command manually again. > >> On the other hand, the vulnerability primarily targets LUKS2 >> reencryption auto-recovery feature. Auto-recovery takes place in two >> scenarios: > ... >> b) LUKS2 device activation e.g. during system boot. > > Okay that's the situation I've had meant before. As described above, this would perform single hotzone segment decryption only (in crash recovery code path). > >> So the recovery from >> reencryption crash is seamless provided user knows passphrase. > > And that's the point where I'd have expected the full decryption, i.e.: > > - an attacker messes with the headers while the device is offline > - the user opens it (e.g. on next boot), doesn't notice anything > - cryptsetup "continues" silently, but actually decrypts No, we do not silently auto-resumes LUKS2 reencryption automatically. > > >> In corner case, when device is small enough to fit limits disclosed >> in >> the vulnerability report (and LUKS2 spare metadata space allows it) >> the >> auto-recovery may actually finish the decryption process (in one >> step). > > I think I don't understand how the spare header space affects this? > > I thought you'd just use that as kind of a journal? And to keep a copy > of the region that is currently re-encrypted, and once that one has > finished it would move on? Yes, In case of 'journal' resilience mode the spare space is 1:1 with hotzone segment size. But if 'checksums' resilience is in-use, the hotzone size can be larger. It stores single digest per encryption sector size block in reencryption hotzone. > >> >> or because an attack started only e.g. at >>> half o the blocks, but then one half is encrypted and the other >>> not? >> >> Nope, in this case device would activate just fine, part of the >> device >> encrypted and part plaintext (multi segment device-mapper device). >> Otherwise we would be unable to activate partially decrypted devices >> due >> to interruption. Same applies to devices in encryption or >> reencryption. > > So you keep book (in a secured way?) on which regions have been re- > encrypted already and which not? > I assumed it would be just some "pointer" that shows at one position > from start to end, where the system currently was. Two possibilities: a) LUKS2 metadata with crashed reencryption: It stores offset and length of the last hotzone. b) LUKS2 metadata after crash recovery: The pointer where to resume the operation when user issues cryptsetup reencrypt command again. > > >> Ransomware attack is not possible provided attacker does not know >> valid >> passphrase or VK, if that's what you're asking: > > That was less about ransomware attack... cause when an attacker would > have access to the offline device, he'd either compromised the system > already, or has physical access... and in both cases he could also just > do the attack (or simply steal the physical device). > > I was rather just wondering, whether during encrypting the new key is > ever written to disk in an insecure way (which they keyslot, where it > is encrypted, wouldn't be) Absolutely not! Keys are always stored in regular LUKS2 keyslots on-disk. > > > >> That would not be possible with LUKS2 format, or better say with >> current >> version of API of libcryptsetup. If the whole header was to be >> protected >> by MAC it would require complete rework of API which would not be >> backward compatible. It would probably be LUKS3 format/library. > > Well... could save us from troubles some day ;-) > > >> Also, just for LUKS2 reencryption, it would completely kill the >> performance of the operation. During LUKS2 reencryption the json >> metadata area gets updated quite often (twice per single reencryption >> step which is typically ~100MiBs of data reencrypteed with checksum >> resilience mode). If we calculated authentication digest (time >> expensive >> operation) in each step twice it would not go fast. FYI, LUKS2 json metadata are stored usually twice per single hotzone reencryption (I. above) > > That refers to the information on which regions have already been re- > encrypted right? yes > > > I assume, unless re-"encryption" to plain text is performed,... the > clear-text never goes on disk during a "normal" re-encryption?! Exactly. It's always either "old" cipher text or "new" ciphertext. Eventually digest(s) of "old" ciphertext depending on what reencryption resilience mode was in-use. Regards O. _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* [dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix) 2022-01-17 11:05 ` Ondrej Kozina @ 2022-01-24 20:50 ` Christoph Anton Mitterer 0 siblings, 0 replies; 6+ messages in thread From: Christoph Anton Mitterer @ 2022-01-24 20:50 UTC (permalink / raw) To: Ondrej Kozina, dm-crypt Hey Ondrej On Mon, 2022-01-17 at 12:05 +0100, Ondrej Kozina wrote: > During auto-recovery triggered by e.g. cryptsetup luksOpen command, > libcryptsetup does not perform whole decryption of device (II., it > only > checks last hotzone (I.) is correcly decrypted. Ah I see... that's the crucial point I had been missing. Thanks a lot for your elaborate explanations :-) Cheers, Chris. _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-24 21:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-13 10:05 [dm-crypt] [ANNOUNCE] cryptsetup 2.4.3 (CVE-2021-4122 fix) Milan Broz 2022-01-13 18:24 ` [dm-crypt] " Christoph Anton Mitterer 2022-01-14 11:18 ` Ondrej Kozina 2022-01-15 4:06 ` Christoph Anton Mitterer 2022-01-17 11:05 ` Ondrej Kozina 2022-01-24 20:50 ` Christoph Anton Mitterer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).