Bug 1845534 (CVE-2020-13776)
| Summary: | CVE-2020-13776 systemd: Mishandles numerical usernames beginning with decimal digits or 0x followed by hexadecimal digits | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Guilherme de Almeida Suckevicz <gsuckevi> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bdettelb, bmontgom, eparis, jbuchert, jburrell, jokerman, lnykryn, lpoetter, msekleta, nstielau, scorneli, sponnaga, ssahani, s, systemd-maint-list, systemd-maint, tomckay, yozone, zbyszek, zjedrzej |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
A flaw was found in systemd, where it mishandles numerical usernames beginning with decimal digits, or "0x" followed by hexadecimal digits. When the usernames are used by systemd, for example in service units, an unexpected user may be used instead. In some particular configurations, this flaw allows local attackers to elevate their privileges.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-18 20:33:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1845535, 1848372, 1848373, 1849896, 1968650, 1968651, 1968652 | ||
| Bug Blocks: | 1845538 | ||
|
Description
Guilherme de Almeida Suckevicz
2020-06-09 13:23:38 UTC
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 |