oss-security - CVE-2020-27781 User credentials can be manipulated and stolen by Native CephFS consumers of OpenStack Manila

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CABBoStgbyztdQ3rcAmjROt5LGLi49j3LqGKjgj9xWgOAEF5vXw@mail.gmail.com>
Date: Wed, 16 Dec 2020 16:08:01 -0500
From: Ana McTaggart <amctagga@...hat.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2020-27781 User credentials can be manipulated and stolen by
 Native CephFS consumers of OpenStack Manila

Dear all,
We have received a report of the following vulnerability affecting CephFS.
At Red Hat, we have assigned it CVE-2020-27781

We are proposing a public date of 12/16/2020, as suggested by the
reporter, but want to ensure agreement with upstream first.
I have included our original description of the flaw as follows.

Issue: User credentials can be manipulated and stolen by Native CephFS
consumers of OpenStack Manila

Products affected: RHCS 3.x, RHCS 4.x

Who reported this vulnerability:
   - Garbutt, John <john@...ngarbutt.com>
   - Babel, Jahson <jahson.babel@...in2p3.fr>;
   - Pacha Ravi, Goutham <gouthamr@...hat.com>;

Details:

OpenStack Manila can provide users with Native CephFS shared file
systems [1]. When a user creates a "share" (short for "shared file
system") via Manila, a CephFS "subvolume" is created on the Ceph
cluster and exported to the manila user. After creating their share, a
user can specify who has access to the share with the help of "cephx"
client user names. A cephx client corresponds to Ceph Client Users
[2]. When access is provided, a client user key is returned via
manila. The interaction between manila and CephFS is driven by two
important parts:
 - The CephFS driver in manila [3]
 - The "ceph_volume_client" python interface driver in ceph [4]

The problem here is that OpenStack Manila users can request access to
a share to any arbitrary cephx user, including privileged pre-existing
users and the interface drivers will retrieve the access key of that
user along with providing access to the share. This access key is then
visible to all users of the OpenStack project that owns the share.
With the help of any prior capabilities of the pre-existing cephx
client user, an attacker has unintended access to the access key of
the user and can target any resource that the user has access to. An
attacker can even obtain the default ceph "admin" user's key in this
manner, and execute any commands as the ceph administrator.

Thanks,
Goutham Pacha Ravi
Project Technical Lead, OpenStack Manila
Sr. Software Engineer, RH OSP Storage

[1] https://docs.openstack.org/manila/latest/admin/cephfs_driver.html
[2] https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/4/html/administration_guide/ceph-user-management
[3] https://opendev.org/openstack/manila/src/commit/7b15796aa5567868e30a6b2b80c57006cfa4f085/manila/share/drivers/cephfs/driver.py
[4] https://github.com/ceph/ceph/blob/c10a7240b657553c366fe62aca92e93d35b166e9/src/pybind/ceph_volume_client.py
[5] https://ceph.io/security/

Ana McTaggart

Red Hat Product Security

Red Hat Remote <https://www.redhat.com>

secalert@...hat.com for urgent response

amct@...hat.com

M: +1 (774)279-0791 <7742790791>     IM: amctagga

Pronouns:They/Them/Theirs

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.