authd: Account takeover via username fallback in identity matching after IdP email reassignment

In authd before 0.7.1, the user identity matching in UpdateUser (internal/users/manager.go) resolves an incoming login by the broker-scoped provider ID, but falls back to matching the username when the provider ID does not belong to any known user, and does not reject a conflicting non-empty provider ID. If an identity provider reassigns an email address, which authd uses as the username, to a new account, the new account inherits the previous user's local UID and home directory on its next login. This allows the new user to access and modify files belonging to the previous user, including credentials such as SSH keys and cloud API tokens, and silently rebinds the local account record to the new identity. As a mitigation, administrators should lock or delete the previous user's local authd account when the corresponding IdP account is removed.

authd Denial of Service and Local Privilege Escalation

authd prior to version 0.6.4 contains a logic error in primary group ID assignment that can lead to local privilege escalation. When a user's primary group ID (GID) differs from their UID, either because the account was created with authd prior to version 0.5.4 or because the primary group was manually changed via the `authctl group set-gid` command, and the user's identity provider record is updated, authd incorrectly resets the user's primary group ID to their UID upon next login. This causes newly created files and directories to be owned by the wrong group, causing denial of service issues, and potentially granting unintended access to other local users and allowing local privilege escalation.

Authd PAM module before version 0.3.5 can allow broker-managed users to impersonate any other user managed by the same broker and perform any PAM operation with it, including authenticating as them.

Authd, through version 0.3.6, did not sufficiently randomize user IDs to prevent collisions. A local attacker who can register user names could spoof another user's ID and gain their privileges.

Improper Permission Management in SSH Session Handling

A flaw was found in the temporary user record that authd uses in the pre-auth NSS. As a result, a user login for the first time will be considered to be part of the root group in the context of that SSH session.