From rosmaita.fossdev at gmail.com Thu Dec 5 17:06:10 2019 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 5 Dec 2019 12:06:10 -0500 Subject: [openstack-announce] [OSSN-0085] Cinder configuration option can leak secret key from Ceph backend Message-ID: <3ffd948f-83ac-75e3-d5d8-0323480601da@gmail.com> Cinder configuration option can leak secret key from Ceph backend --- ### Summary ### This vulnerability is present only when Cinder has a Ceph backend *and* the ``rbd_keyring_conf`` option in the Cinder configuration file is set. (The option is unset by default.) Under these circumstances, the keyring content may be leaked to a regular user. ### Affected Services / Software ### Cinder, Pike, Queens, Rocky, Stein, Train ### Discussion ### When the ``rbd_keyring_conf`` option is set, a user who creates a volume and then does a local attach of that volume using the Cinder REST API, may discover the keyring content for the Ceph cluster. (This does not apply to the normal Nova attach process. The user must contact the Cinder REST API directly for this exploit.) If this user then gains access to the Ceph cluster independently of Cinder, these credentials may be used to access any volume in the cluster. This issue was reported by Raphael Glon of OVH. NOTE: This issue is different from OSSA-2019-003, through which Ceph credentials could be leaked from the Nova REST API during error conditions, but we suggest you take this opportunity to review that security advisory and make sure your system has been updated or patched to address it: https://security.openstack.org/ossa/OSSA-2019-003.html ### Recommended Actions ### Any installation currently using the ``rbd_keyring_conf`` option should immediately stop using that option. In order for Cinder backups to continue working, the Ceph keyring secrets should be deployed directly on cinder-backup hosts in their standard location: /etc/ceph/.client..keyring The ``rbd_keyring_conf`` is deprecated in the Ussuri release and will be removed early in the 'V' development cycle. There is no replacement planned for this functionality. ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0085 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1849624 Mailing List : [Security] tag on openstack-discuss at lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg From gagehugo at gmail.com Wed Dec 11 16:32:14 2019 From: gagehugo at gmail.com (Gage Hugo) Date: Wed, 11 Dec 2019 10:32:14 -0600 Subject: [openstack-announce] [OSSA-2019-006] Credentials API allows listing and retrieving of all users credentials (CVE-2019-19687) Message-ID: ===================================================================================== OSSA-2019-006: Credentials API allows listing and retrieving of all users credentials ===================================================================================== :Date: December 09, 2019 :CVE: CVE-2019-19687 Affects ~~~~~~~ - Keystone: ==15.0.0, ==16.0.0 Description ~~~~~~~~~~~ Daniel Preussker reported a vulnerability in Keystone's list credentials API. Any user with a role on a project is able to list any credentials with the /v3/credentials API when [oslo_policy] enforce_scope is false. Users with a role on a project are able to view any other users credentials, which could leak sign-on information for Time-based One Time Passwords (TOTP) or othewise. Deployments running keystone with [oslo_policy] enforce_scope set to false are affected. There will be a slight performance impact for the list credentials API once this issue is fixed. Patches ~~~~~~~ - https://review.opendev.org/697731 (Stein) - https://review.opendev.org/697611 (Train) - https://review.opendev.org/697355 (Ussuri) Credits ~~~~~~~ - Daniel Preussker (CVE-2019-19687) References ~~~~~~~~~~ - https://bugs.launchpad.net/keystone/+bug/1855080 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19687 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAl3xGeUACgkQ56j9K3b+ vRGIFw/8CNnL2aDqOi+7AcCH5alknVoWJS5Dd/EymQVDI07vbe4yneghwcQwEs6S BUR25+xB5ukjPJdxsILTrm4UbhEMPUzjgT7PQN71Q1/ge8XY1YIRzBwMnjYm0nQr sYRBl8L1OQ3CQsAtnH+hB/qMCkxlQeXtOMiBcz3/1B2qcH/AruXtJxhVD9swJHew fOn5WNdODlDPKCmls0xK6csZX4RBcsXc04aPr3fSuOIzcwNZ260sr+8MfeTr3mi3 SO4t2uYQgQmhgaPnvM3tyMFa+ry+mFvq6MFigPUhp+Akd0eYasHa3rg6/I/LQO0Z ImWCSAnjntWigbyhQhLrxIIEdoxu/vgTVCciPWtgwMfxDOLw1jhj3kBzdeb3S5pA yoyY1+H8nXaze2UQOfbM1FHyO2cTkOjyzVdbrF5bg8vNl4haL5egu6UVD018H5pc voJwcrxgJUobO+kTzuOpjWzlHeqRryLXDhH191cVKoUBIgIpi0KEbyBOIAwMNciU vkvNqRDi9rGfaM+QWUWgf12G2FRnkqmFqbnlLY6hpz5uinueEVn7iTC2LnfBA+Um GX0qsWv4L3dQXf9rtTdCNpGvw7nsBGcqYqUw9C7piAVKfGDZ6LBiuQbseW+ONLCK 7vq7rLyJq9JCjwIWr53d8lLp0hLTrV/bH5hcICusEY3WfH+cJZs= =pUkl -----END PGP SIGNATURE-----