Summary {field}.isFilterable access control can be bypassed in update and delete mutations by adding additional unique filters. These filters can be used as an oracle to probe the existence or value of otherwise unreadable fields.
Specifically, when a mutation includes a where clause with multiple unique filters (e.g. id and email), Keystone will attempt to match records even if filtering by the latter fields would normally be rejected by field.isFilterable or list.defaultIsFilterable. This can allow malicious actors to infer the presence of a particular field value when a filter is successful in returning a result.
Impact This affects any project relying on the default or dynamic isFilterable behaviour (at the list or field level) to prevent external users from using the filtering of fields as a discovery mechanism. While this access control is respected during findMany operations, it was not completely enforced during update and delete mutations when accepting more than one unique where values in filters.
This has no impact on projects using isFilterable: false or defaultIsFilterable: false for sensitive fields, or if you have otherwise omitted filtering by these fields from your GraphQL schema. (See workarounds)
Patches This issue has been patched in @keystone-6/core version 6.5.0.
Workarounds To mitigate this issue in older versions where patching is not a viable pathway.
- Set isFilterable: false statically for relevant fields to prevent filtering by them earlier in the access control pipeline (that is, don't use functions) - Set {field}.graphql.omit.read: true for relevant fields, which implicitly removes filtering by these fields your GraphQL schema - Deny update and delete operations for the relevant lists completely (e.g list({ access: { operation: { update: false, delete: false } }, ... }))
The (1) mamcache and (2) KVS token backends in OpenStack Identity (Keystone) Folsom 2012.2.x and Grizzly before 2013.1.4 do not properly compare the PKI token revocation list with PKI tokens, which allow remote attackers to bypass intended access restrictions via a revoked PKI token.
The V3 API in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 updates the issuedat value for UUID v2 tokens, which allows remote authenticated users to bypass the token expiration and retain access via a verification (1) GET or (2) HEAD request to v3/auth/tokens/.
The MySQL token driver in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 stores timestamps with the incorrect precision, which causes the expiration comparison for tokens to fail and allows remote authenticated users to retain access via an expired token.
OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 does not properly revoke tokens when a domain is invalidated, which allows remote authenticated users to retain access via a domain-scoped token for that domain.
OpenStack Identity (Keystone) Folsom 2012.2.4 and earlier, Grizzly before 2013.1.1, and Havana does not immediately revoke the authentication token when deleting a user through the Keystone v2 API, which allows remote authenticated users to retain access via the token.
OpenStack Identity (Keystone) Grizzly 2013.1.1, when DEBUG mode logging is enabled, logs the (1) admintoken and (2) LDAP password in plaintext, which allows local users to obtain sensitive by reading the log file.
DISPUTED OpenStack Keystone through 14.0.1 has a user enumeration vulnerability because invalid usernames have much faster responses than valid ones for a POST /v3/auth/tokens request. NOTE: the vendor's position is that this is a hardening opportunity, and not necessarily an issue that should have an OpenStack Security Advisory.
The identity service in OpenStack Identity (Keystone) before 2015.1.3 (Kilo) and 8.0.x before 8.0.2 (Liberty) and keystonemiddleware (formerly python-keystoneclient) before 1.5.4 (Kilo) and Liberty before 2.3.3 does not properly invalidate authorization tokens when using the PKI or PKIZ token providers, which allows remote authenticated users to bypass intended access restrictions and gain access to cloud resources by manipulating byte fields within a revoked token.
tools/sampledata.sh in OpenStack Keystone 2012.1.3, when access to Amazon Elastic Compute Cloud (Amazon EC2) is configured, uses world-readable permissions for /etc/keystone/ec2rc, which allows local users to obtain access to EC2 services by reading administrative access and secret values from this file.
OpenStack Identity (Keystone) Folsom, Grizzly 2013.1.3 and earlier, and Havana before havana-3 does not properly revoke user tokens when a tenant is disabled, which allows remote authenticated users to retain access via the token.
OpenStack Keystone Folsom, Grizzly before 2013.1.3, and Havana, when using LDAP with Anonymous binding, allows remote attackers to bypass authentication via an empty password.
OpenStack Keystone Essex 2012.1.3 and earlier, Folsom 2012.2.3 and earlier, and Grizzly grizzly-2 and earlier allows remote attackers to cause a denial of service (disk consumption) via many invalid token requests that trigger excessive generation of log entries.
OpenStack Keystone Grizzly before 2013.1, Folsom 2012.1.3 and earlier, and Essex does not properly check if the (1) user, (2) tenant, or (3) domain is enabled when using EC2-style authentication, which allows context-dependent attackers to bypass access restrictions.
The catalog url replacement in OpenStack Identity (Keystone) before 2013.2.3 and 2014.1 before 2014.1.2.1 allows remote authenticated users to read sensitive configuration options via a crafted endpoint, as demonstrated by "$(admintoken)" in the publicurl endpoint field.
OpenStack Identity (Keystone) before 2013.2.4, 2014.x before 2014.1.2, and Juno before Juno-2 allows remote authenticated trustees to gain access to an unauthorized project for which the trustor has certain roles via the project ID in a V2 API trust token request.
OpenStack Identity (Keystone) before 2014.1.1 does not properly handle when a role is assigned to a group that has the same ID as a user, which allows remote authenticated users to gain privileges that are assigned to a group with the same ID.
OpenStack Identity (Keystone) before 2014.1.5 and 2014.2.x before 2014.2.4 logs the backendargument configuration option content, which allows remote authenticated users to obtain passwords and other sensitive backend information by reading the Keystone logs.
A flaw was found in Keystone federation. By doing GET /v3/OS-FEDERATION/projects an authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected.
A flaw was found in openstack-keystone, only the first 72 characters of an application secret are verified allowing attackers bypass some password complexity which administrators may be counting on. The highest threat from this vulnerability is to data confidentiality and integrity. A patch is available.
Thierry Carrez reports:
Title: Token revocation failure using Keystone memcache/KVS backends Reporter: Kieran Spear (University of Melbourne) Products: Keystone Affects: Folsom, Grizzly
Description: Kieran Spear from the University of Melbourne reported a vulnerability in Keystone memcache and KVS token backends. The PKI token revocation lists stored the entire token instead of the token ID, triggering comparison failures, ultimately resulting in revoked PKI tokens still being considered valid. Only Folsom and Grizzly Keystone setups making use of PKI tokens with the memcache or KVS token backends are affected. Havana setups, setups using UUID tokens, or setups using PKI tokens with the SQL token backend are all unaffected.
Thierry Carrez (thierry) reports:
Title: Missing expiration check in Keystone PKI token validation Reporter: Eoghan Glynn (Red Hat) Products/Affects: Keystone (Folsom only), python-keystoneclient (0.2.0+)
Description: Eoghan Glynn from Red Hat reported a vulnerability in expiry checks for PKI tokens in the Keystone authentication middleware. Expired tokens for authenticated users could continue to be used, potentially resulting in the bypass of intended security policies. The effect of PKI token revocation is also reversed when the token expires, in the sense that a revoked token is once again treated as being valid. Only setups using PKI tokens are affected.
Note: The affected code was added to Keystone in the Folsom release, but was moved to python-keystoneclient during the Grizzly development cycle.
Thierry Carrez (thierry) of the OpenStack Project reports:
Title: Keystone denial of service through invalid token requests Reporter: Dan Prince (Red Hat) Products: Keystone Affects: All versions
Description: Dan Prince of Red Hat reported a vulnerability in token creation error handling in Keystone. By requesting lots of invalid tokens, an unauthenticated user may fill up logs on Keystone API servers disks, potentially resulting in a denial of service attack against Keystone.
Proposed patches: See attached patches for current development tree (Grizzly) and the Folsom and Essex series. Unless a flaw is discovered in them, these proposed patches will be merged to Keystone master, stable/folsom and stable/essex branches on the public disclosure date.
Within the OpenStack keystone package the file /etc/keystone/ec2rc is world readable and contains:
=== ADMINACCESS=109a7daa83054fc58ec8ade83b114117 ADMINSECRET=3bbbcba9514e4e8e8d0eb9e528754091 DEMOACCESS=81c2326383e34b888e0589057bc7fae2 DEMOSECRET=ceb87a47838a442ea2923ad1bd6f0a16 ===
Also please note that the /etc/keystone/ directory should probably not be world readable at all.
The OpenStack project reports:
"" Title: Configuration option leak through Keystone catalog Reporter: Brant Knudson (IBM) Products: Keystone Versions: up to 2013.2.3 and 2014.1 versions up to 2014.1.2.1
Description: Brant Knudson from IBM reported a vulnerability in Keystone catalog URL replacement. By creating a malicious endpoint a privileged user may reveal configuration options resulting in sensitive information, like master admintoken, being exposed through the service url. All Keystone setups that allow non-admin users to create endpoints are affected. ""
Acknowledgements:
Red Hat would like to thank the OpenStack project for reporting this issue. Upstream acknowledges Brant Knudson from IBM as the original reporter.
A flaw was found in Keystone federation. By doing GET /v3/OS-FEDERATION/projects an authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected.
An authenticated user may receive all the roles assigned to the user's project regardless of the federation mapping when there are rules in which group-based assignments are not used. For example, by requesting an admin user to get a role in their project, the user may be granted the admin privileges for new scoped tokens. All setups using the Keystone federation with projects auto-provisioning and no group based assignments rules are affected.
Affected versions: 10.0.0, 10.0.1, 11.0.0
Rohit Karajgi discovered a vulnerability in OpenStack Keystone token handling:
Token authentication for a user belonging to a disable tenant should not be allowed.
External References: https://bugs.launchpad.net/keystone/+bug/988920