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

[Ondrej Kozina <okozina@redhat.com>]

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