[dm-crypt] [ANNOUNCE] cryptsetup 2.4.3 (CVE-2021-4122 fix)

[dm-crypt] [ANNOUNCE] cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Milan Broz]

[-- 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

[dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Christoph Anton Mitterer]

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

[dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Ondrej Kozina]

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

[dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Christoph Anton Mitterer]

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

[dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Ondrej Kozina]

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

[dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Christoph Anton Mitterer]

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