Bug 2334165 (CVE-2024-56433)
| Summary: | CVE-2024-56433 shadow-utils: Default subordinate ID configuration in /etc/login.defs could lead to compromise | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | awilliam, debarshir, dustymabe, jcapitao, travier, walters, wshi |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
A flaw was found in shadow-utils. Affected versions of shadow-utils establish a default /etc/subuid behavior, for example, uid 100000 through 165535 for the first user account, that can conflict with the uids of users defined on locally administered networks. This issue potentially leads to account takeover by leveraging newuidmap for access to an NFS home directory or same-host resources for remote logins by these local network users.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2334168, 2334169 | ||
| Bug Blocks: | |||
|
Description
OSIDB Bzimport
2024-12-26 09:01:18 UTC
This breaks effectively all realistic default usage of podman rootless containers for new installs (or new users in existing installs), which is a pretty large impact. As is it would mean everyone who wants to do that would need to ensure their provisioned systems re add the uid ranges. We have the inverse problem too in that applying this update won’t actually fix the problem if somehow existing uids do overlap! Really I think the deliverable for this CVE should probably be a tool that can be run to analyze/adjust if there is actually a clash, not just disable the functionality globally by default. yeah, breaking podman out of the box is pretty bad. It broke some openQA tests, and I just found my way here trying to figure out why. Dug into this and found some discussion, particularly at https://github.com/shadow-maint/shadow/issues/1157 . I think the relatively 'low' range 100000 through 165535 was specifically chosen to avoid conflict with FreeIPA, which 'reserves' a range of 200000 IPs on install. By default it does this to pick the start of the range: random.randint(1, 10000) * 200000 which means it will never start lower than 200000, but it might use *any* UID above 200000. However, this makes a conflict much more likely with a large non-FreeIPA site, if it just started at 1000 and counted up, or whatever - that seems to be the situation the reporter of the github issue found themselves in. FYI there is a broader discussion going on at https://bugzilla.redhat.com/show_bug.cgi?id=2382662 This issue has been addressed in the following products: Red Hat Enterprise Linux 10 Via RHSA-2025:20145 https://access.redhat.com/errata/RHSA-2025:20145 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2025:20559 https://access.redhat.com/errata/RHSA-2025:20559 |