Compliance Impact

This vulnerability allows an attacker to execute arbitrary code as root by injecting malicious NSS modules if the new root directory is writable. Such a privilege escalation or container escape can lead to unauthorized access to sensitive data and system resources.

Consequently, this can impact compliance with standards and regulations like GDPR and HIPAA, which require strict controls over data confidentiality, integrity, and access. Exploitation of this vulnerability could result in data breaches or unauthorized data processing, violating these regulatory requirements.

Useful 0 Not Useful 0

Executive Summary

This 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 environment but before dropping root privileges. On systems using glibc, this process can cause the Name Service Switch (NSS) to load shared libraries from the new root directory. If the new root directory is writable by an attacker, they can inject a malicious NSS module, which can then execute arbitrary code with root privileges.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to a full container escape or privilege escalation. An attacker who can write to the new root directory can inject malicious code that executes with root privileges, potentially compromising the entire system or container.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves checking if the uutils/coreutils chroot utility is used with the --userspec option and whether the new root directory (NEWROOT) is writable by untrusted users.

One can inspect the permissions of the new root directory to ensure it is not writable by attackers, as writable NEWROOT allows injection of malicious NSS modules.

Additionally, monitoring for unexpected creation of files outside the chroot jail (e.g., /tmp/pwned) after running chroot commands with --userspec may indicate exploitation.

Suggested commands include:

• Check permissions of the new root directory: ls -ld /path/to/newroot
• Check for suspicious shared libraries inside the new root: find /path/to/newroot -name 'libnss_*.so.2'
• Run chroot with --userspec on a test user and check for unexpected files outside the jail, e.g., ls /tmp/pwned

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include ensuring that the new root directory used with chroot is not writable by untrusted users or attackers.

Avoid using the --userspec option with the vulnerable uutils/coreutils chroot utility until a patch is applied.

Apply updates or patches provided by the uutils/coreutils project or your distribution that fix the issue by dropping privileges before resolving the user specification.

As a temporary workaround, use the GNU coreutils chroot utility instead of the vulnerable uutils/coreutils version, as the PoC shows it is not vulnerable.

Useful 0 Not Useful 0