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

Regards,
Salvatore

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 E. Hallyn <serge@hallyn.com> [250422 15:48]:

Should there be some form of documentation update, like a README?

What else would be "sufficient" to close this topic?

Chris

Hi Chris, hi Serge,

Sorry I seem to not have been clear when filling the bugreport. Yes I
do understand the problem, and was pursuading/checking if it might be
worth/sufficient having it documented in upstream. Or what else we
should do.

Hope I explained now in a more sensible way. Thanks Chris.

Regards,
Salvatore

Maybe debian changelog?
ranges, we should exclude userids which are in use in /etc/passwd.  We
are currently assuming that any range above the SUB_ID_START is wholly
ours.  Or, maybe that should at least have a login.defs option (which
then could be default-on in debian).

That way all network users would need to be defined in passwd, but
at least there'd be a way of doing that.

Of course another alternative for the users is to implement an NSS module.

While testing to make sure it isn't doing that now, I did also notice
that if you do adduser --uid 200000 sj1, then sj1 does not get a
subid range auto-assigned.  While just adduser sj2 does.  That seems
inconsistent...

Or maybe simply add a note in the existing README.Debian?

Cheers,
        Moritz

Hi,

In my opinion if it can be added to upstream documentation that would
be ideal, but agree that for Debian purposes otherwise we can add a
note on the problem to the README.Debian (or both in the end).

Chris, what do you think with you maintainer hat on here?

Regards,
Salvatore

I was hoping there would be some upstream activity on this.
Unfortunately https://github.com/shadow-maint/shadow/issues/1157
seems completely stalled.

Not sure it makes sense to keep tracking this.

BR,
Chris

Hi Chris,

I asked in
https://github.com/shadow-maint/shadow/issues/1157#issuecomment-4701723167
. I would say if there is no plan to otherwise handle it upstream with
a documentation update then it might be still worth as Moritz suggested
to a Debian specific README.Debian and be done with it.

Regards,
Salvatore

Jun 14, 2026 08:21:17 Salvatore Bonaccorso <carnil@debian.org>:

I'm open to a note in the subid manpages.

IMO in a zero trust architecture and with the ability to uid shift vfsmounts this is mostly a lazy regulator problem, but as I have seen the same issue in my workplace, i am sympathetic and have no issues with a balanced, brief discussion of the issue and ramifications there. Subuid manpage seems the best place, but I'm open to other suggestions.