OpenStack Keystone vulnerabilities

In OpenStack Keystone before 29.0.3, any authenticated user with role:reader on any project can list every project-scoped role assignment under any domain by passing a domain ID as scope.project.id with include_subtree to the GET /v3/role_assignments endpoint. The domain's project record has domain_id=null, causing the policy domain_id check to pass for any caller. With include_names, the response discloses names and home-domain IDs of all users, groups, projects, and roles. An attacker can harvest domain IDs and repeat the query to map role assignments across the entire cloud.

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 OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.

In OpenStack Keystone before version 29.0.2, a vulnerability combined with application credential impersonation allows an attacker with the member role on a project to escalate to admin. The attacker creates unrestricted application credentials and chains them with Keystone trusts, impersonating the victim and taking over their admin role.

In OpenStack Keystone before 29.0.2, the RBAC policy enforcer in enforce_call unconditionally merges the raw JSON request body into the policy enforcement dictionary via policy_dict.update(json_input.copy()), overwriting trusted target data that was previously set from database lookups. Because flask.request.get_json is called with force=True, this works regardless of Content-Type or HTTP method. Any authenticated user can inject arbitrary policy target attributes (e.g., user_id, project_id) into the request body to bypass RBAC checks and perform unauthorized operations on resources belonging to other users or projects. This was introduced in commit 5ea59f52 (Rocky/14.0.0).

In OpenStack Keystone before version 29.0.2, the POST /v3/credentials endpoint did not validate that the caller-supplied project_id for an EC2 credential matched the project of the authenticating application credential. An attacker with an unrestricted application credential for project A could create an EC2 credential targeting project B, then exchange it for a Keystone token scoped to project B while retaining the original app_cred_id.

In OpenStack Keystone before version 28.0.1, the LDAP identity backend does not convert the user enabled attribute to a boolean when the user_enabled_invert configuration option is False (the default). This causes users disabled in LDAP to be treated as enabled by Keystone, allowing them to authenticate and perform actions.

A flaw in OpenStack Keystone allows a remote attacker to send a large HTTP request with a long tenant name when requesting a token, leading to excessive CPU and memory consumption and denial of service.