Barbican is including the contents of the request query string in the target data that is used by oslo.policy to enforce policy.
Since oslo.policy uses this data to do string interpolation into the policy rules before enforcing the policy, it gives a malicious user the opportunity to craft query strings to manipulate the policy in arbitrary ways.
For example, a malicious user with a Keystone account is able to decrypt any secret as long as they know the secret's ID by using a specifically crafted query string:
GET /v1/secrets/{secret-id}/payload?target.secret.read=read
Using this query string, the malicious user is able to fool Barbican into thinking that the user is in the ACL for the secret, which allows for secret decryption. Since the query string is applied to the target data after the data is fetched from the database, the user-provided query string overrides any values stored in the DB. In this case, overriding "target.secret.read" to "read", which should only be set when a user is added to the ACL.
This issue has been addressed in the following products:
Red Hat OpenStack Platform 16.1
Red Hat OpenStack Platform 16.2
Red Hat OpenStack Platform 17.0
Red Hat OpenStack Platform 13.0 (Queens) for RHEL 7.6 EUS
Red Hat OpenStack Platform 13.0 - ELS
Via RHSA-2022:6750 https://access.redhat.com/errata/RHSA-2022:6750
Barbican is including the contents of the request query string in the target data that is used by oslo.policy to enforce policy. Since oslo.policy uses this data to do string interpolation into the policy rules before enforcing the policy, it gives a malicious user the opportunity to craft query strings to manipulate the policy in arbitrary ways. For example, a malicious user with a Keystone account is able to decrypt any secret as long as they know the secret's ID by using a specifically crafted query string: GET /v1/secrets/{secret-id}/payload?target.secret.read=read Using this query string, the malicious user is able to fool Barbican into thinking that the user is in the ACL for the secret, which allows for secret decryption. Since the query string is applied to the target data after the data is fetched from the database, the user-provided query string overrides any values stored in the DB. In this case, overriding "target.secret.read" to "read", which should only be set when a user is added to the ACL.