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: carnil@debian.org, Debian Security Team <team@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

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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: carnil@debian.org, Debian Security Team <team@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Serge E. Hallyn <serge@hallyn.com> [250422 15:48]:

On Mon, Apr 21, 2025 at 08:08:50PM +0200, Salvatore Bonaccorso wrote:

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.

Indeed. The question really is: what are we gonna do?

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

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

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 22, 2025 at 09:46:14PM +0200, Chris Hofstaedtler wrote:

* Serge E. Hallyn <serge@hallyn.com> [250422 15:48]:

On Mon, Apr 21, 2025 at 08:08:50PM +0200, Salvatore Bonaccorso wrote:

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.

Indeed. The question really is: what are we gonna do?

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

Maybe debian changelog?

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

Well, maybe we can improve one thing in adduser: when selecting subid
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...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 23, 2025 at 05:04:22PM -0500, Serge E. Hallyn wrote:

On Tue, Apr 22, 2025 at 09:46:14PM +0200, Chris Hofstaedtler wrote:

* Serge E. Hallyn <serge@hallyn.com> [250422 15:48]:

On Mon, Apr 21, 2025 at 08:08:50PM +0200, Salvatore Bonaccorso wrote:

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.

Indeed. The question really is: what are we gonna do?

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

Maybe debian changelog?

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

Cheers,
Moritz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)