[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Jan 2022 22:52:24 -0600
From: John Helmert III <ajak@...too.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2021-3979 ceph: Ceph volume does not honour
osd_dmcrypt_key_size
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@...h3:~$ cat /etc/ceph/ceph.conf
> ...
> [osd]
> osd_dmcrypt_type = luks
> osd_cryptsetup_parameters = --cipher aes-xts-plain64
> osd_dmcrypt_key_size = 512
>
> markir@...h3:~$ 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 <=========== 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?
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
