[pkg-cryptsetup-devel] Security issue (CVE-2021-4122) in cryptsetup 2:2.3.5-1

[Guilhem Moulin]

Hi corsac,

On Tue, 01 Feb 2022 at 11:11:45 +0100, Yves-Alexis Perez wrote:
> I took a look at the various proposals and here's my summary / feelings on
> this.

Many thanks for the detailed summary!

> I don't think [disable-reencryption] alone is really a good idea. We risk
> preventing legitimate users to reencrypt their devices easily,

Agreed.

> while in the attacker model I'm not sure it wouldn't be possible to
> replace the cryptsetup binaries in the initramfs with an older,
> vulnerable one anyway (same thing for any fixed version actually).

Yup, more generally one needs early-boot integrity guaranties to detect
tampering; that's also true for the rest of the content of the initramfs
image, such as coreutil binaries, and that's beyond the scope of this
update.

> I'm usually inclined to follow upstream on security updates since they usually
> know better their own software. Especially since the fix involves a large
> number of commits anyway, I think it'd be best to get it through v2.3.7.
> 
> So the real question here, I guess, is whether we want to also get
> [truncation-fix] in bullseye-security (and later bullseye), considering it was
> initially skipped. I think that fix now had some exposure from unstable and
> testing, and I think I'd be ok with letting it go to bullseye, but I'd welcome
> other opinion on this.

The one thing I feel a bit uneasy about is the absence of smooth upgrade path:

  * cryptsetup/2:2.1.0-5+deb10u2 (Buster) silently truncates keys at 114 bytes
    (for some time between the Stretch and Buster releases we even
    silently truncated at 106 bytes)
  * cryptsetup/2:2.3.5-1 (Bullseye) refuses to open dm-integrity devices
    using HMAC integrity protection with keys ≥113 bytes long (in
    reality it's a little more complicated since it depends on the
    kernel version and on the flags passed to libdevmapper, but let's
    assume a stock Bullseye system with default options here)
  * For cryptsetup/2:2.3.7-1+deb11u1 and cryptsetup/2:2.4.3-1 (Bookworm, sid) there
    is no key truncation on the integritysetup side and HMAC integrity
    key length is only bound by libdevmapper's internal limits

So someone upgrading from cryptsetup/2:2.1.0-5+deb10u2 to 2:2.3.5-1
would experience a hard failure (the device wouldn't map) and hopefully
file a bug on our BTS, while when jumping to 2:2.3.7-1+deb11u1 they'd
see confusing I/O errors.  Of course, this “only” applies to standalone
dm-integrity devices with a keyed checksum *and* when key lengths are
arguably beyond reason, so quite a corner case.  (In particular dm-crypt
devices, incl. authenticated disk encryption, are unaffected since long
keys aren't used as is but instead hashed internally before mapping the
device.)

As you wrote cryptsetup/2:2.4.0-1 with the truncation fix entered
testing over 5 months ago so got some exposure there, and almost 6
months after the Bullseye release and with 2 point releases under our
belt we've yet to see a complain that standalone dm-integrity devices
aren't usable with ≥113 bytes long HMAC(SHA256) keys.  I've not seen
anything on the upstream BTS either.

We'll have to break compatibility at some point, and I don't have a
strong opinion whether it's best to wait for Bookwork or bite the
bullet and do it now for 11.3 through bullseye-security.  I think it's
best to follow your and the rest of the security team's advice and
preference :-)  New debdiff against 2:2.3.5-1 attached and tested (incl.
the full privileged upstream test suite).

Given the rare corner case we didn't mention the incompatibility in
cryptsetup/2:2.4.0-1's NEWS file, and didn't either for cryptsetup/2:2.3.7-1+deb11u1 .
Let us know if you think a NEWS entry is required here.

Cheers
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cryptsetup-2.3.debdiff.gz
Type: application/gzip
Size: 287098 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20220201/d7e62d8e/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20220201/d7e62d8e/attachment.sig>