* [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).