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