Bug 1845534 (CVE-2020-13776) - CVE-2020-13776 systemd: Mishandles numerical usernames beginning with decimal digits or 0x followed by hexadecimal digits
Summary: CVE-2020-13776 systemd: Mishandles numerical usernames beginning with decimal...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-13776
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1968651 1845535 1848372 1848373 1849896 1968650 1968652
Blocks: 1845538
TreeView+ depends on / blocked
 
Reported: 2020-06-09 13:23 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-10-19 07:01 UTC (History)
20 users (show)

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.
Clone Of:
Environment:
Last Closed: 2021-05-18 20:33:51 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:3900 0 None None None 2021-10-19 07:01:17 UTC

Description Guilherme de Almeida Suckevicz 2020-06-09 13:23:38 UTC
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

Comment 1 Guilherme de Almeida Suckevicz 2020-06-09 13:23:57 UTC
Created systemd tracking bugs for this issue:

Affects: fedora-all [bug 1845535]

Comment 3 Riccardo Schirone 2020-06-16 12:59:01 UTC
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.

Comment 5 Riccardo Schirone 2020-06-16 13:26:50 UTC
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.

Comment 6 Riccardo Schirone 2020-06-16 13:28:47 UTC
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]+).

Comment 7 Riccardo Schirone 2020-06-16 13:43:29 UTC
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.

Comment 8 Zbigniew Jędrzejewski-Szmek 2020-06-17 14:17:03 UTC
> 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.

Comment 12 errata-xmlrpc 2021-05-18 13:40:54 UTC
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

Comment 13 Product Security DevOps Team 2021-05-18 20:33:51 UTC
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

Comment 15 errata-xmlrpc 2021-10-19 07:01:15 UTC
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


Note You need to log in before you can comment on or make changes to this bug.