On Mon, Apr 21, 2025 at 08:08:50PM +0200, Salvatore Bonaccorso wrote: > Source: shadow > Version: 1:4.13+dfsg1-1 > Severity: important > Tags: security upstream > Forwarded: https://github.com/shadow-maint/shadow/issues/1157 > X-Debbugs-Cc: car...@debian.org, Debian Security Team > <t...@security.debian.org> > > Hi, > > The following vulnerability was published for shadow. > > CVE-2024-56433[0]: > | shadow-utils (aka shadow) 4.4 through 4.17.0 establishes a default > | /etc/subuid behavior (e.g., uid 100000 through 165535 for the first > | user account) that can realistically conflict with the uids of users > | defined on locally administered networks, potentially leading to > | account takeover, e.g., by leveraging newuidmap for access to an NFS > | home directory (or same-host resources in the case of remote logins > | by these local network users). NOTE: it may also be argued that > | system administrators should not have assigned uids, within local > | networks, that are within the range that can occur in /etc/subuid. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > Thought this will not really be fixable in code, it depends on how > uids were assigned in within a group of systems form system > administrators. Let's link downstream bugreport and upstream and maybe > they come up with a documentation update reflecting the issue? > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2024-56433 > https://www.cve.org/CVERecord?id=CVE-2024-56433 > [1] https://github.com/shadow-maint/shadow/issues/1157
There is no id range that couldn't possibly conflict with some site's network ids. The only default safe for that concern is to not automatically enable any subids. But then, any network service or network filesystem should be using some authentication - certificates, keyfiles, passphrases, a 4 -digit pin! We worried 25 years ago about someone plugging a laptop where they were root into a switch in the network closet... I'd also note that so long as the uidmap package is not installed, newuidmap is not installed, so while the range is allocated, users can't actually make use of their range. Does that suffice? If /etc/subuid and /etc/subgid do not exist, then useradd should not add subuids. Likewise if SUB_UID_COUNT = 0 in login.defs. But there is no explicit "do not use subuids" setting in login.defs right now. -serge
