Default subordinate ID configuration in /etc/login.defs could lead to compromise

[JonnyWhatshisface]

Trying to find the right place to bring this up to, as I'm not sure whether shadow-utils is shipping this out like this or if it's the distributions that have distributed it like this.

I'm seeing on Red Hat 9 and Debian 12 that login.defs is shipping with SUB_UID_* configuration resulting in /etc/subuid and /etc/subgid entries for local accounts being added to the system.

This can have unintended consequences, as it assumes the systems are running in an environment where there would be no ID's on the network that fall within the ranges handed out by this configuration.

The issue is that the subordinate ID's can easily become the effective UID/GID of the account they're assigned to. For example, my local account had an entirely unexpected subordinate ID range assigned to it which happens to overlap with a user ID on my network. With minimal effort I'm able to become that ID and write to the users NFS home directory.

jon@localhost ~]$ id;uname -a;cat /etc/subuid
uid=1000(jon) gid=1000(jon) groups=1000(jon),10(wheel)
Linux localhost.localdomain 5.14.0-503.14.1.el9_5.aarch64 #1 SMP PREEMPT_DYNAMIC Fri Nov 15 07:14:03 EST 2024 aarch64 aarch64 aarch64 GNU/Linux
jon:100000:65536
[jon@localhost ~]$ getent passwd msteph
msteph:x:108472:108472::/mnt/home/msteph:/bin/bash
[jon@localhost ~]$ ls -al subdo;getcap subdo
-rwxr-xr-x 1 jon jon 72936 Dec 22 23:12 subdo
[jon@localhost ~]$ ./subdo -u 108472 -g 108472 -r 1 bash
bash: /home/jon/.bashrc: Permission denied
bash-5.1$ id
uid=108472(msteph) gid=108472(msteph) groups=108472(msteph),65534(nobody)
bash-5.1$ cd ~msteph
bash-5.1$ ls
bash-5.1$ ls -al
total 16
drwx------ 3 msteph nobody 99 Dec 22 23:19 .
drwxr-xr-x. 8 nobody nobody 85 Dec 22 23:18 ..
-rw------- 1 msteph msteph 20 Dec 22 23:19 .bash_history
-rw-r--r-- 1 msteph nobody 18 Apr 30 2024 .bash_logout
-rw-r--r-- 1 msteph nobody 141 Apr 30 2024 .bash_profile
-rw-r--r-- 1 msteph nobody 492 Apr 30 2024 .bashrc
drwxr-xr-x 4 msteph nobody 39 Dec 20 09:10 .mozilla
bash-5.1$ touch testing123
bash-5.1$ ls -aal
total 16
drwx------ 3 msteph nobody 117 Dec 22 23:23 .
drwxr-xr-x. 8 nobody nobody 85 Dec 22 23:18 ..
-rw------- 1 msteph msteph 20 Dec 22 23:19 .bash_history
-rw-r--r-- 1 msteph nobody 18 Apr 30 2024 .bash_logout
-rw-r--r-- 1 msteph nobody 141 Apr 30 2024 .bash_profile
-rw-r--r-- 1 msteph nobody 492 Apr 30 2024 .bashrc
drwxr-xr-x 4 msteph nobody 39 Dec 20 09:10 .mozilla
-rw-r--r-- 1 msteph msteph 0 Dec 22 23:23 testing123
bash-5.1$

[ikerexxe]

This can have unintended consequences, as it assumes the systems are running in an environment where there would be no ID's on the network that fall within the ranges handed out by this configuration.

That's one way of seeing things, but I have another one in mind. The remote server doesn't take into account that lower ID's might be used in the system and tries to use an ID that is already allocated to subordinate ID ranges. This is a gray area since there is no range of IDs assigned for centrally managed users. The issue of ID assignment was already addressed when the assignment of subordinates for centrally managed users was implemented #154 (comment) and
#154 (comment) to name a few.

Some projects like FreeIPA define the ID range allocation for a number that is big enough to avoid this type of collision. Unfortunately this isn't always the case, and it's up to the sysadmin to define the boundaries correctly to avoid this type of problem.

By the way, this problem could happen in other cases as well, such as centrally managed user IDs being assigned to values below 1000. So there is a collision with the range of system users. This case is not theoretical, but I saw it a little over a year ago. The system administrator should try to avoid these problems by assigning values that do not collide with each other.

[JonnyWhatshisface]

Unfortunately, in larger enterprise environments (including the one I recently left which is a 170k machine RH shop) - these default subordinate ID ranges are low enough that the likeliness of collision becomes very high. For example, in that said previous environment, the first local user given a range of 100000-165535 results in collision with more than 8,000 valid ID's, giving potential for severe internal privilege escalation in what is a publicly regulated environment.

I think the biggest problem here stems from two things:

1. The default range chosen is low enough that it increases the likeliness of collision. Even in my own personal network I've run in to a collision as demonstrated above.

2. Most system administrators are entirely unaware of this configuration and thus may be unaware of the risk lying quietly in their infrastructure

I found this purely by coincidence because I already have incredibly complex and large subuid/subgid configurations in my infrastructure. I was confused about where the entries came from and initially assumed I must have done it and forgotten about it.

I've spoken with a few directors from four separate multinational organizations who have confirmed their operations and engineering teams were entirely unaware of this default behaviour. Llikewise, all 4 have identified and confirmed collisions with ID's within just the first delegated range assigned to local accounts created on the system both with adduser/useradd and through the user addition at install time.

I do believe that raising the starting range to somewhere in the billions would do more to reduce the likeliness of collision, but I also believe that defaulting delegation of subordinate ID's within any range is something better left to the administrators to configure and should probably not be a default configuration out of the box.

[ikerexxe]

1. The default range chosen is low enough that it increases the likeliness of collision. Even in my own personal network I've run in to a collision as demonstrated above.

Choosing a higher range of IDs would have meant a higher risk of collision with other suppliers. There is no perfect solution and this needs to be assessed very carefully.

2. Most system administrators are entirely unaware of this configuration and thus may be unaware of the risk lying quietly in their infrastructure

This is a big problem, but there is no way to contact each of them to make sure they have understood it correctly before enabling a new feature like this.

I do believe that raising the starting range to somewhere in the billions would do more to reduce the likeliness of collision, but I also believe that defaulting delegation of subordinate ID's within any range is something better left to the administrators to configure and should probably not be a default configuration out of the box.

I prefer the second option since the first one as I mentioned would probably cause collisions with other environments.

CC'ing @abbra @alexey-tikhonov

[JonnyWhatshisface]

I agree with both of your sentiments.

• A documentation update would not be sufficient alone because there is high a probability that many people may not even understand what the subordinate ID's are or how they work. This is especially true in large environments where SOD becomes a factor. (speaking from experience)

• No range you set will guarantee not risking collisions. Thus, this "feature" is something that should only be enabled explicitly by the administrators who wish to use it. For regulated environments, this can create a major PCI and SOX problem.

It begs to question: what was the intended purpose of adding this default configuration? Whatever it is, I suspect the risk it introduces far outweighs whatever the benefit in doing so is.

[carnil]

FTR: According to CVE-2024-56433 has been assigned.

[alexey-tikhonov]

Choosing a higher range of IDs would have meant a higher risk of collision with other suppliers. There is no perfect solution and this needs to be assessed very carefully.

If you want to keep auto assignment then, imo, 2147483648…4294967294 range would be the best bet as it doesn't conflict systemd (https://systemd.io/UIDS-GIDS/) and matches what IPA does.

[JonnyWhatshisface]

One thing to keep in mind is that in Financial environments regulated by FINRA, allowing any system account or network user to arbitrarily change ID’s is a major problem. In those cases, even if you increase the default range to a high enough range that collision is unlikely, it still puts such environments at risk of running in to issues with regulators. I believe the right answer here is to disable it by default entirely. Why is it needed? What benefit are you gaining from assigning arbitrary subordinate id delegations as a default for local users?

[abbra]

Note that pluggable subid support does not allow to use multiple subid modules, so if you are supplying subid mappings via SSSD from a centralized source (e.g. FreeIPA), the local source (/etc/subuid and /etc/subgid) would not be used at all.
In FreeIPA we do not allocate subids to users by default, it has to be an explicit action done centrally first.

For purely local setup I believe it should also be done explicitly. However, we still cannot agree with systemd folks on a way to jointly define and manage ID ranges used for various types of objects in the ID space. Sadly, most of allocation decisions therefore are static.