Re: CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: John Helmert III &lt;ajak () gentoo org&gt;

Date: Tue, 11 Jan 2022 22:52:24 -0600

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
On Tue, Jan 11, 2022 at 04:10:06PM -0500, Ana McTaggart wrote:
Hi all,
The key length for encrypted devices created using ceph-volume is
incorrect. This is due to a bug in ceph_volume/util/encryption.py, where
upon writing a key using osd_dmcrypt_key_size it does not pass the key size
to the format and open operations following. The default key is then
applied in cryptsetup. All versions since Luminous are assumed affected. At
Red Hat. we have assigned it  CVE-2021-3979 and proposed a CVSS score of
6.5/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

See below for the report, credit of Mark Kirkwood.

We happened to run 'cryptsetup luksDump' on some of our encrypted
devices that were created using ceph-volume and noticed the key length
was wrong:

e.g:

markir@ceph3:~$ cat /etc/ceph/ceph.conf
...
[osd]
osd_dmcrypt_type = luks
osd_cryptsetup_parameters = --cipher aes-xts-plain64
osd_dmcrypt_key_size = 512

markir@ceph3:~$ sudo cryptsetup luksDump
/dev/mapper/ceph--9e3502c0--a991--44cc--a2a1--0e8e8fb45189-osd--block--aaab9851--5951--429d--8e9d--dbc22ea4c1a1

Version:           1
Cipher name:       aes
Cipher mode:       xts-plain64
Hash spec:         sha256
Payload offset:    4096
MK bits:           256 &lt;=========== should be 512

This appears to be due to a bug in ceph_volume/util/encryption.py. While
it writes a key using osd_dmcrypt_key_size it does not pass the key size
to the following format and open operations. It looks like that ecause
the key is being passed to cryptsetup on stdin that the length is not
being deduced, and so the default key size is being applied.

It is fairly simple to patch (see attached - luks operation only, prob
needs plain code path altered similarly).

In terms of which versions are impacted, we are running Luminous, but
the patch I have attached is against current master, so suspect all
versions since Luminous are in the crosshairs.

Was a patch meant to be attached? Is there any report or PR upstream?Attachment:
signature.asc
Description: 

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size Ana McTaggart (Jan 11)

Re: CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size Jeffrey Walton (Jan 12)

Re: CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size John Helmert III (Jan 12)

Re: CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size Sven Kieske (Jan 12)

Re: CVE-2021-3979 ceph: Ceph volume does not honour osd_dmcrypt_key_size Ana McTaggart (Jan 12)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->