Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2020-13776: User names beginning with 0x being interpreted as user identifiers · Issue #15985 · systemd/systemd

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.

CVE
#microsoft#git

Comments

@0x2b3bfa0

eworm-de added a commit to eworm-de/systemd that referenced this issue

Jun 23, 2020

@keszybz@eworm-de

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

(cherry picked from commit 156a5fd)

vbatts pushed a commit to kinvolk/systemd that referenced this issue

Nov 12, 2020

@keszybz

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

(cherry picked from commit 156a5fd)

bluca added a commit to bluca/systemd that referenced this issue

Jul 9, 2021

@keszybz@bluca

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

CVE: CVE-2020-13776 Upstream-Status: Backport [systemd@156a5fd]

Signed-off-by: Dan Tran [email protected]

russell-islam added a commit to russell-islam/systemd that referenced this issue

Jul 21, 2021

@keszybz@russell-islam

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

CVE: CVE-2020-13776 Upstream-Status: Backport [systemd@156a5fd]

Signed-off-by: Dan Tran [email protected]

mikhailnov added a commit to mikhailnov/systemd that referenced this issue

Aug 10, 2021

@keszybz@mikhailnov

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

mikhailnov added a commit to mikhailnov/systemd that referenced this issue

Aug 10, 2021

@keszybz@mikhailnov

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

mikhailnov added a commit to mikhailnov/systemd that referenced this issue

Aug 10, 2021

@keszybz@mikhailnov

We would parse numbers with base prefixes as user identifiers. For example, “0x2b3bfa0” would be interpreted as UID==45334432 and “01750” would be interpreted as UID==1000. This parsing was used also in cases where either a user/group name or number may be specified. This means that names like 0x2b3bfa0 would be ambiguous: they are a valid user name according to our documented relaxed rules, but they would also be parsed as numeric uids.

This behaviour is definitely not expected by users, since tools generally only accept decimal numbers (e.g. id, getent passwd), while other tools only accept user names and thus will interpret such strings as user names without even attempting to convert them to numbers (su, ssh). So let’s follow suit and only accept numbers in decimal notation. Effectively this means that we will reject such strings as a username/uid/groupname/gid where strict mode is used, and try to look up a user/group with such a name in relaxed mode.

Since the function changed is fairly low-level and fairly widely used, this affects multiple tools: loginctl show-user/enable-linger/disable-linger foo’, the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d, etc.

Fixes systemd#15985.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907