Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux