Skip to content

Authd allows attacker-controlled usernames to yield controllable UIDs

Moderate severity GitHub Reviewed Published Oct 10, 2024 in ubuntu/authd • Updated Oct 11, 2024

Package

gomod github.com/ubuntu/authd (Go)

Affected versions

<= 0.0.0-20230706090440-d8cb2d561419

Patched versions

None

Description

CVE description:

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.

----- original report -----

Cause

authd assigns user IDs as a pure function of the user name. Moreover, the set of UIDs is much too small for pseudo-random assignment to work: the birthday bound predicts random collisions will occur with probability 50% after only 54 562 IDs were assigned.

authd only checks for uniqueness within its local cache, which

  • may be inconsistent across multiple systems within the same domain ;
  • may be purged, due to being stored in /var/cache ;
  • automatically removes entries of users who have not logged into that specific system within the last 6 months.

The current GenerateID method, authored in September 2024 (commit a6c85ed24b8d17a2d11c859e8d70f5a52fa69690),
repeatedly hashes the user name until the 4 leading bytes fall into the interval [60 000; 2³¹[ :
https://github.com/ubuntu/authd/blob/f9f851540e6377fca18a45ce7a02d024c1dbd6e9/internal/users/manager.go#L425
https://github.com/ubuntu/authd/blob/f9f851540e6377fca18a45ce7a02d024c1dbd6e9/internal/services/nss/nss.go#L188

Previous versions are affected by similar issues, though without the use of a cryptographic hash in GenerateID, making exploitation computationally-easier.

Impact

Since GenerateID is a pure function with no secret input, and the set of UIDs is small, an adversary which can register users with chosen names can

  • register multiple users with colliding IDs, or
  • register a single user whose ID collides with a target user's, whether one managed by authd, or a system user whose well-known ID is in a range which overlaps authd's.

In the latter case, as all access control performed by the Linux kernel (and other Unices' kernels) is based on IDs and not usernames, if the attacker can sign into a system, they will have the same privileges as the target user. The attacker can bypass the uniqueness check in (at least) the following ways:

  • engineer a situation where the system administrator purges /var/cache ;
  • target a system account whose UID is in authd's range ;
  • target an account which hasn't logged into a specific system in more than 6 months.
    Note that this isn't limited to inactive accounts within the entire domain, and impersonation on a given system can potentially be leveraged to compromise the target account on other systems; for example:
    • user alice is known to log into 1.example.com ;
    • the attacker computes a preimage (a username which yields the same UID), let's call it bob ;
    • the attacker creates the account bob and logs into 2.example.com, succeeding if alice hasn't (recently) logged into that system ;
    • the attacker can now manipulate resources exposed on 2 as if they were alice; assuming /home is shared, they could manipulate ~alice/.ssh/authorized_keys, ~alice/.config, alice's shell's initialization file, etc.
      Note: NFSv4's idmap mechanism may prevent this, but isn't enabled by default (unless Kerberos is used, which isn't the case in an authd deployment)
    • at that point, gaining code execution as alice on 1.example.com is usually trivial.

Since the necessary computation can be performed entirely offline, this wouldn't be affected by any rate-limits, and the only audit trail would be a single user registration. This would require on average less than 2³¹ computations of GenerateID: assuming SHA-256's cost is 25 cycles-per-byte, a clock speed of 3GHz, and short (≤32B) generated usernames, this is less than 10 minutes of a single core's time.

Remediation

The simplest and likely-best remediation path would be for the external IdP to provide a guaranteed-unique user ID in the correct range.
In OIDC, this is commonly communicated through a claim, though its name would need to be configurable as there's no real standard:

This is also supported by other commonplace identity providers, such as LDAP and Active Directory:
https://learn.microsoft.com/en-us/windows/win32/adschema/a-uidNumber

MS Entra presumably supports this as well.

If that is not possible for some reason, architectural changes to authd would likely be required:
assigning user IDs from a small space (such as Linux's 32b UIDs) requires mutable state to ensure uniqueness, whereas authd's design currently assumes no mutable state is held, aside from some transient, local cache.
Moreover, that mutable state may need to be synchronised across multiple machines as uniform UIDs are often necessary, for instance when accessing a common networked filesystem.

Acknowledgements

Thanks to Michael Gebetsroither for assisting with the writeup, and Jamie Bliss for the same as well as investigating when the issue was introduced in authd.

References

@didrocks didrocks published to ubuntu/authd Oct 10, 2024
Published by the National Vulnerability Database Oct 10, 2024
Published to the GitHub Advisory Database Oct 10, 2024
Reviewed Oct 10, 2024
Last updated Oct 11, 2024

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required High
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H

EPSS score

0.043%
(10th percentile)

Weaknesses

CVE ID

CVE-2024-9312

GHSA ID

GHSA-4gfw-wf7c-w6g2

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.