systemd through v245 mishandles numerical usernames such as ones composed of decimal digits or 0x followed by hex digits, as demonstrated by use of root privileges when privileges of the 0x0 user account were intended. NOTE: this issue exists because of an incomplete fix for CVE-2017-1000082. Reference: https://github.com/systemd/systemd/issues/15985
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1845535]
Upstream fixes: https://github.com/systemd/systemd/commit/156a5fd297b61bce31630d7a52c15614bf784843 https://github.com/systemd/systemd/commit/6495ceddf38aed2c9efdcf9d3440140190800b55
When a service uses the `User=` directive with a user name that starts with `0x`, the service may be started with the wrong user. If a local user has a username that can be interpreted as an hexadecimal number (e.g. 0x0) if an admin tries to start a service as that user, the service may instead be executed as another user, maybe with higher privileges. In some circumstances the local user may be able to use this unintended behavior to elevate his privileges.
A local user may be able to elevate his privileges if the affected service unit executes a file that the user has access to and that he can modify. In such a case, the attacker could alter the executed binary to execute additional code with root privileges. In other cases this flaw may raise the impact of exploiting a flaw in a vulnerable service. If the admin runs a service with the intention of limiting its privileges to those of a regular user (e.g. "0x0") the service will be instead run as root and exploiting it would result in root privileges instead of the intended limited ones.
Mitigation: Do not use `User=` directive in services with numerical usernames composed by decimal digits or starting with "0x" followed by hexadecimal digits (e.g. 0x[0-9A-Fa-f]+).
Statement: The flaw is rated as Moderate because several uncommon conditions have to be met to make it exploitable. Numerical usernames with decimal digits or starting with "0x" followed by hexadecimal digits must exist on the system. Systemd would need to process those particular usernames (e.g. while using the `User=` directive in a systemd service unit). If the service was supposed to run as a regular user and the binary being executed can be controlled by a local attacker, he could abuse this flaw to unexpectedly execute code as a root when the service is started. If the service was run as a regular user to limit the impact of a possible flaw in the service, this flaw would not provide the intended additional protection.
> unexpectedly execute code as a root when the service is started No, as that numerical uid, not root, unless the name is 0x0. > several uncommon conditions have to be met to make it exploitable Note that there's an additional condition: the user with the numerical value of the Ox... username must exist. E.g. for user 0xdeadbeef, we also need uid 3735928559 to be defined and own soem files. If there is no such user, strictly speaking the hole is still there, but running as a user which is not defined is similar to running as nobody, and in general doesn't give significant additional privileges. I'd rate this as "low". The practical impact of this is that people can't log in as their user, and not that they run as a different one.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1611 https://access.redhat.com/errata/RHSA-2021:1611
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-13776
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2021:3900 https://access.redhat.com/errata/RHSA-2021:3900