yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #80891
[Bug 1855080] Re: Credentials API allows listing and retrieving of all users credentials
Reviewed: https://review.opendev.org/697355
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=17c337dbdbfb9d548ad531c2ad0483c9bce5b98f
Submitter: Zuul
Branch: master
commit 17c337dbdbfb9d548ad531c2ad0483c9bce5b98f
Author: Colleen Murphy <colleen.murphy@xxxxxxx>
Date: Wed Dec 4 10:51:05 2019 -0800
Fix credential list for project members
Without this patch, project members and readers can list any credentials
with the /v3/credentials API when enforce_scope is false. enforce_scope
is only applicable to project admins due to the admin-ness problem[1],
and this policy is not meant to allow project admins any access to users'
credentials (only system admins should be able to access them). However,
when enforce_scope is false, we need to preserve the old behavior of
project admins being able to list all credentials. This change mitigates
the problem by running the identity:get_credential policy check to
filter out credentials the user does not have access to. This will
impact performance.
Closes-bug: #1855080
[1] https://bugs.launchpad.net/keystone/+bug/968696
Change-Id: I5dd85a6b8368373a27aef2942a64499d020662ef
** Changed in: keystone
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1855080
Title:
Credentials API allows listing and retrieving of all users credentials
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Security Advisory:
Confirmed
Status in keystone package in Ubuntu:
New
Bug description:
Tested against Stein and Train.
# User creating a credential, i.e totp or similar
$ OS_CLOUD=1 openstack token issue
| project_id | c3caf1b55bb84b78a795fd81838e5160
| user_id | 9971b0f13d2d4a578212d028a53c3209
$ OS_CLOUD=1 openstack credential create --type test 9971b0f13d2d4a578212d028a53c3209 test-data
$ OS_CLOUD=1 openstack credential list
+----------------------------------+------+----------------------------------+-----------+------------+
| ID | Type | User ID | Data | Project ID |
+----------------------------------+------+----------------------------------+-----------+------------+
| 0a3a2d3b7dad4886b0bbf61b6cd7d2b0 | test | 9971b0f13d2d4a578212d028a53c3209 | test-data | None |
+----------------------------------+------+----------------------------------+-----------+------------+
# Different User but same Project
$ OS_CLOUD=2 openstack token issue
| project_id | c3caf1b55bb84b78a795fd81838e5160
| user_id | 6b28a0b073fc4ac7843f33190ebc5c3c
$ OS_CLOUD=2 openstack credential list
+----------------------------------+------+----------------------------------+-----------+------------+
| ID | Type | User ID | Data | Project ID |
+----------------------------------+------+----------------------------------+-----------+------------+
| 0a3a2d3b7dad4886b0bbf61b6cd7d2b0 | test | 9971b0f13d2d4a578212d028a53c3209 | test-data | None |
+----------------------------------+------+----------------------------------+-----------+------------+
# Different User and Different Project
$ OS_CLOUD=3 openstack token issue
| project_id | d43f20ae5a7e4f36b701710277384401
| user_id | 2e48f1a7d1474391a826a2b9700e5949
$ OS_CLOUD=3 openstack credential list
+----------------------------------+------+----------------------------------+-----------+------------+
| ID | Type | User ID | Data | Project ID |
+----------------------------------+------+----------------------------------+-----------+------------+
| 0a3a2d3b7dad4886b0bbf61b6cd7d2b0 | test | 9971b0f13d2d4a578212d028a53c3209 | test-data | None |
+----------------------------------+------+----------------------------------+-----------+------------+
As shown anyone who's authenticated can retrieve any credentials
including their 'secret'.
This is a rather severe information disclosure vulnerability and
completely defies the purpose of TOTP or MFA as these credentials are
not kept secure or private whatsoever.
If Auth-rules are configured allow login with only 'topt' it would be
extremely easy to assume a different user's identity.
A CVE should be issued for this. I can take care of that paperwork.
Versions affected and tested:
Train/ubuntu:
$ dpkg -l | grep keystone
ii keystone 2:16.0.0-0ubuntu1~cloud0 all OpenStack identity service - Daemons
ii keystone-common 2:16.0.0-0ubuntu1~cloud0 all OpenStack identity service - Common files
ii python-keystoneauth1 3.13.1-0ubuntu1~cloud0 all authentication library for OpenStack Identity - Python 2.7
ii python-keystoneclient 1:3.19.0-0ubuntu1~cloud0 all client library for the OpenStack Keystone API - Python 2.x
ii python-keystonemiddleware 6.0.0-0ubuntu1~cloud0 all Middleware for OpenStack Identity (Keystone) - Python 2.x
ii python3-keystone 2:16.0.0-0ubuntu1~cloud0 all OpenStack identity service - Python 3 library
ii python3-keystoneauth1 3.17.1-0ubuntu1~cloud0 all authentication library for OpenStack Identity - Python 3.x
ii python3-keystoneclient 1:3.21.0-0ubuntu1~cloud0 all client library for the OpenStack Keystone API - Python 3.x
ii python3-keystonemiddleware 7.0.1-0ubuntu1~cloud0 all Middleware for OpenStack Identity (Keystone) - Python 3.x
Stein/RHEL:
$ rpm -qa | grep keystone
python3-keystoneclient-3.19.0-0.20190312070330.6c4bb8b.el8ost.noarch
openstack-keystone-15.0.1-0.20190720060412.5f27c4b.el8ost.noarch
python3-keystoneauth1-3.13.1-0.20190311052414.bde07bc.el8ost.noarch
python3-keystonemiddleware-6.0.0-0.20190312071144.fca37ea.el8ost.noarch
python3-keystone-15.0.1-0.20190720060412.5f27c4b.el8ost.noarch
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1855080/+subscriptions
