From: Christoph Anton Mitterer <calestyo@scientia.net>
To: dm-crypt@saout.de
Subject: [dm-crypt] Re: cryptsetup 2.4.3 (CVE-2021-4122 fix)
Date: Thu, 13 Jan 2022 19:24:59 +0100 [thread overview]
Message-ID: <c4bb84c7f13521651e124fa01e926c3a8d7d7301.camel@scientia.net> (raw)
In-Reply-To: <005d7ce6-161e-c00d-2317-efd88095175d@gmail.com>
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
next prev parent reply other threads:[~2022-01-13 19:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2022-01-14 11:18 ` [dm-crypt] " 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4bb84c7f13521651e124fa01e926c3a8d7d7301.camel@scientia.net \
--to=calestyo@scientia.net \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).