New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User names beginning with 0x being interpreted as user identifiers #15985
Comments
|
Adding the You could test for a string username before trying the parameter as a UID, but that can lead to unpredictable behaviour (e.g. create a username |
POSIX.1-2017
|
|
@Malvineous, you're right: user names can be |
I don't know if such a drastic change is a good idea, as the underlying
Or, better yet, check that the passed string is fully numeric before trying to interpret it as an user identifier, as per my suggestion in #15987. However, creating a username
I don't think so, as this code is being used in many more places (see #6237). If we intend to clearly differentiate user identifiers and user names, many breaking changes will be required. |
|
https://access.redhat.com/solutions/3103631 seems to provide a good insight on this issue |
|
The RedHat link is interesting, because it suggests that at some point I wonder whether you could pick a character that isn't allowed in a username, like '#' or '@' (can't use '#' because it often starts a comment though, not sure about '@'), and when that appears as the first character in the username, the rest of it is treated as a UID. Otherwise it's treated as a username if one exists, and only falls back to a UID if there is no matching username. That would allow you to specify You'd only run into problems with this solution if you were using a UID now, and you had a username on the system that matched that UID but itself had a different UID. Not sure why any sane person would do that, but the solution would be to just add '@' onto the front of the UID. |
Yes it even links to #6237 here on GitHub: «[...] towards the end of the bug report [...]»
Certainly, your proposed solution would be more elegant and practical.
Yes, this seems to be a reasonable approach and it's even listed in the Red Hat link above:
|
|
Oh I didn't get that far in the Red Hat article, sorry about that! If coreutils uses a Also, I see |
Yes, that would make sense, and your out-of-the-box thinking was really accurate.
I would like to add that |
By the way, |
|
I've updated #15987 with a proposed fix, but it keeps being |
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)
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)
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 <dantran@microsoft.com>
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 <dantran@microsoft.com>
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.
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.
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.
Version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Affected code
systemd/src/basic/user-util.c
Line 717 in d904afc
systemd/src/basic/user-util.c
Line 52 in d904afc
systemd/src/basic/parse-util.h
Line 53 in d904afc
systemd/src/basic/parse-util.h
Line 49 in d904afc
systemd/src/basic/parse-util.c
Line 375 in d904afc
Problem description
As per the
strtoul(3)manpage, when thebaseargument is0, the string can also be interpreted as an hexadecimal or octal number:Vulnerability
Related issues
The text was updated successfully, but these errors were encountered: