Описание
In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.
A flaw was found in OpenStack Keystone where an application credential token can escape its intended project scope through token-method reauthentication. Keystone rejects an explicit scope change for an application credential token, but an omitted scope falls through to the owner's default project. If the owner has roles on that default project, Keystone issues a new token scoped there while still carrying the original application credential identity. Custom Keystone authentication plugins are subject to the same incomplete rescope guard. This allows a limited-scope application credential for one project to access another project within the owner's role assignments.
Отчет
This vulnerability is rated as Important because an authenticated user with an application credential can escape the credential's project binding through token reauthentication and access the owner's default project. Custom Keystone authentication plugins can be affected in the same way. Exploitation requires a valid application credential and a different default project where the owner also has roles. Application credential reauthentication only becomes practically exploitable from Keystone 27.0.1 on the 27.x stable line, and from 28.0.0 on the 28.x line. On earlier versions, exchanging an application credential token fails before a new token is issued. Red Hat OpenStack Platform 16.2, 17.1, and 18.0 (including RHOSO) ship openstack-keystone versions below 27.0.1 and are not affected. A separately identified weakness in EC2 credential reauthentication is outside the scope of this CVE and is being documented by upstream as residual exposure. Client libraries such as python-keystoneclient, python-keystoneauth1, and python-keystonemiddleware do not contain the vulnerable Keystone server code and are not affected.
Меры по смягчению последствий
Set the following in keystone.conf to prevent exchanging a scoped token for a token with a different project scope: [token] allow_rescope_scoped_token = False This blocks the application-credential default-project fallback. It also prevents Horizon project switching for users who authenticate with a scoped token. This setting does not disable application credentials themselves.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat OpenStack Platform 16.2 | openstack-keystone | Not affected | ||
| Red Hat OpenStack Platform 17.1 | openstack-keystone | Not affected | ||
| Red Hat OpenStack Platform 18.0 | openstack-keystone | Not affected |
Показывать по
Ссылки на источники
Дополнительная информация
Статус:
7.1 High
CVSS3
Связанные уязвимости
In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.
In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.
In OpenStack Keystone before 29.0.3, tokens obtained via delegated aut ...
In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.
7.1 High
CVSS3