REDHAT-BUG-2530888: Medium severity SSSD SSSD vulnerability
A flaw was found in SSSD's IdP authentication provider. The evalaccesstokenbuf() function in src/providers/idp/idpautheval.c compares the authenticated user's OIDC subject identifier against the requested user's stored SYSDBUUID using strncmp() with the authenticated identifier's length as the count. This performs a prefix comparison rather than an exact match. An attacker whose complete IdP identifier is a strict prefix of a target user's identifier can authenticate as the target, gaining full access to the target's account, files, groups, and local authorization. With Keycloak's built-in LDAP provider (Import Users disabled), the identifier format f:<federationid>:<username> naturally produces prefix relationships for usernames like 'admin' and 'administrator'. No victim credential, interaction, or administrative role is required.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Deployments using SSSD's IdP authentication provider are exposed when one user's complete OIDC subject identifier is a strict prefix of another user's stored SYSDB_UUID. Keycloak using its built-in LDAP provider with Import Users disabled can naturally create these prefix relationships for usernames such as "admin" and "administrator".
What does an attacker need to exploit it?
The attacker needs an IdP identifier that is a strict prefix of the target user's identifier and must authenticate through the affected IdP path. No victim credentials, victim interaction, or administrative role is required.
What access can successful exploitation provide?
A successful attacker can authenticate as the target user and obtain full access to that user's account, files, groups, and local authorization.