A vulnerability exists in the chroot utility of uutils coreutils when using the –userspec option. The utility resolves the user specification via getpwnam() after entering the chroot but before dropping root privileges. On glibc-based systems, this can trigger the Name Service Switch (NSS) to load shared libraries (e.g., libnss_*.so.2) from the new root directory. If the NEWROOT is writable by an attacker, they can inject a malicious NSS module to execute arbitrary code as root, facilitating a full container escape or privilege escalation.
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product’s direct control.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Coreutils | Uutils | - (including) | - (including) |
| Rust-coreutils | Ubuntu | devel | * |
| Rust-coreutils | Ubuntu | esm-apps/noble | * |
| Rust-coreutils | Ubuntu | noble | * |
| Rust-coreutils | Ubuntu | questing | * |
| Rust-coreutils | Ubuntu | resolute | * |
| Rust-coreutils | Ubuntu | upstream | * |
This might allow attackers to execute their own programs, access unauthorized data files, or modify configuration in unexpected ways. If the product uses a search path to locate critical resources such as programs, then an attacker could modify that search path to point to a malicious program, which the targeted product would then execute. The problem extends to any type of critical resource that the product trusts. Some of the most common variants of untrusted search path are: