| 2020-10-28 13:32:05 |
Arjen |
bug |
|
|
added bug |
| 2020-10-28 17:32:54 |
Jeremy Stanley |
description |
While looking into the application credential API we came across several issues. Since they are all closely related I will file them under this issue:
- No secret strength requirements. To configure a password strength requirement for users, one can use `password_regex`. However, this is not possible for application credentials, which makes it possible to create a credentials with the secret 'a':
$ openstack application credential create test-secret-strength --secret a
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| description | None |
| expires_at | None |
| id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| name | test-secret-strength |
| project_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| roles | member reader |
| secret | a |
| system | None |
| unrestricted | False |
| user_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
+--------------+----------------------------------+
To attack this, you'd still need to know the ID, but combined with https://bugs.launchpad.net/keystone/+bug/1901207 the impact of this issue is increased.
- No lockout feature. For normal login, the settings `lockout_failure_attempts` and `lockout_duration` are used. These do not affect the application credential API. This increases the attack surface unnecessarily in my opinion. Combined with weak secrets and https://bugs.launchpad.net/keystone/+bug/1901207 the probability of a successful attack is increased.
- Only part of secret is verified. It looks like only the first 72 characters of the secret of an application credential are used to verify it. Characters after that are not used in the verification. The default length of a secret seems to be 86 characters. Even though brute forcing 72 characters is still pretty impossible, this doesn't sound like intended behaviour to me. |
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2021-01-26 and will be made
public by or on that date even if no fix is identified.
While looking into the application credential API we came across several issues. Since they are all closely related I will file them under this issue:
- No secret strength requirements. To configure a password strength requirement for users, one can use `password_regex`. However, this is not possible for application credentials, which makes it possible to create a credentials with the secret 'a':
$ openstack application credential create test-secret-strength --secret a
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| description | None |
| expires_at | None |
| id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| name | test-secret-strength |
| project_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| roles | member reader |
| secret | a |
| system | None |
| unrestricted | False |
| user_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
+--------------+----------------------------------+
To attack this, you'd still need to know the ID, but combined with https://bugs.launchpad.net/keystone/+bug/1901207 the impact of this issue is increased.
- No lockout feature. For normal login, the settings `lockout_failure_attempts` and `lockout_duration` are used. These do not affect the application credential API. This increases the attack surface unnecessarily in my opinion. Combined with weak secrets and https://bugs.launchpad.net/keystone/+bug/1901207 the probability of a successful attack is increased.
- Only part of secret is verified. It looks like only the first 72 characters of the secret of an application credential are used to verify it. Characters after that are not used in the verification. The default length of a secret seems to be 86 characters. Even though brute forcing 72 characters is still pretty impossible, this doesn't sound like intended behaviour to me. |
|
| 2020-10-28 17:33:18 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2020-10-28 17:33:46 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2020-10-28 17:34:11 |
Jeremy Stanley |
bug |
|
|
added subscriber Keystone Core security contacts |
| 2021-01-21 17:47:24 |
Gage Hugo |
description |
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2021-01-26 and will be made
public by or on that date even if no fix is identified.
While looking into the application credential API we came across several issues. Since they are all closely related I will file them under this issue:
- No secret strength requirements. To configure a password strength requirement for users, one can use `password_regex`. However, this is not possible for application credentials, which makes it possible to create a credentials with the secret 'a':
$ openstack application credential create test-secret-strength --secret a
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| description | None |
| expires_at | None |
| id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| name | test-secret-strength |
| project_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| roles | member reader |
| secret | a |
| system | None |
| unrestricted | False |
| user_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
+--------------+----------------------------------+
To attack this, you'd still need to know the ID, but combined with https://bugs.launchpad.net/keystone/+bug/1901207 the impact of this issue is increased.
- No lockout feature. For normal login, the settings `lockout_failure_attempts` and `lockout_duration` are used. These do not affect the application credential API. This increases the attack surface unnecessarily in my opinion. Combined with weak secrets and https://bugs.launchpad.net/keystone/+bug/1901207 the probability of a successful attack is increased.
- Only part of secret is verified. It looks like only the first 72 characters of the secret of an application credential are used to verify it. Characters after that are not used in the verification. The default length of a secret seems to be 86 characters. Even though brute forcing 72 characters is still pretty impossible, this doesn't sound like intended behaviour to me. |
While looking into the application credential API we came across several issues. Since they are all closely related I will file them under this issue:
- No secret strength requirements. To configure a password strength requirement for users, one can use `password_regex`. However, this is not possible for application credentials, which makes it possible to create a credentials with the secret 'a':
$ openstack application credential create test-secret-strength --secret a
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| description | None |
| expires_at | None |
| id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| name | test-secret-strength |
| project_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| roles | member reader |
| secret | a |
| system | None |
| unrestricted | False |
| user_id | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
+--------------+----------------------------------+
To attack this, you'd still need to know the ID, but combined with https://bugs.launchpad.net/keystone/+bug/1901207 the impact of this issue is increased.
- No lockout feature. For normal login, the settings `lockout_failure_attempts` and `lockout_duration` are used. These do not affect the application credential API. This increases the attack surface unnecessarily in my opinion. Combined with weak secrets and https://bugs.launchpad.net/keystone/+bug/1901207 the probability of a successful attack is increased.
- Only part of secret is verified. It looks like only the first 72 characters of the secret of an application credential are used to verify it. Characters after that are not used in the verification. The default length of a secret seems to be 86 characters. Even though brute forcing 72 characters is still pretty impossible, this doesn't sound like intended behaviour to me. |
|
| 2021-01-21 17:47:31 |
Gage Hugo |
information type |
Private Security |
Public Security |
|
| 2021-02-17 20:49:36 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2021-02-17 20:49:42 |
Jeremy Stanley |
information type |
Public Security |
Public |
|
| 2021-02-17 20:49:52 |
Jeremy Stanley |
tags |
|
security |
|
| 2021-05-21 15:13:37 |
Nick Tait |
cve linked |
|
2021-3563 |
|
| 2021-08-05 18:30:14 |
OpenStack Infra |
keystone: status |
New |
In Progress |
|
| 2022-02-10 15:38:26 |
David Wilde |
keystone: assignee |
|
David Wilde (dave-wilde) |
|
| 2022-10-28 20:20:22 |
Luis Flores |
bug |
|
|
added subscriber Luis Flores |
| 2023-02-28 16:47:46 |
OpenStack Infra |
keystone: status |
In Progress |
Fix Released |
|
| 2023-08-07 13:27:51 |
OpenStack Infra |
tags |
security |
in-stable-zed security |
|
| 2023-08-25 16:28:54 |
OpenStack Infra |
tags |
in-stable-zed security |
in-stable-yoga in-stable-zed security |
|
| 2023-09-01 13:19:17 |
OpenStack Infra |
tags |
in-stable-yoga in-stable-zed security |
in-stable-xena in-stable-yoga in-stable-zed security |
|
| 2023-09-06 15:56:58 |
OpenStack Infra |
tags |
in-stable-xena in-stable-yoga in-stable-zed security |
in-stable-wallaby in-stable-xena in-stable-yoga in-stable-zed security |
|
| 2023-09-07 17:22:11 |
OpenStack Infra |
tags |
in-stable-wallaby in-stable-xena in-stable-yoga in-stable-zed security |
in-stable-victoria in-stable-wallaby in-stable-xena in-stable-yoga in-stable-zed security |
|
