Canonical's consideration to switch from GNU coreutils to uutils coreutils has revealed significant security vulnerabilities, with an audit uncovering 44 CVEs that raise questions about the readiness of the Rust implementation for production systems.
Canonical's recent announcement about potentially switching from GNU coreutils to uutils coreutils has sparked intense discussion in the Linux community. This transition represents a significant architectural shift, replacing decades of C-based implementations with a modern Rust rewrite. However, security audits have revealed concerning vulnerabilities that may impact Ubuntu's adoption timeline.
Canonical's update details the comprehensive audit performed by Zellic, which uncovered 113 issues across the uutils coreutils implementation. Of these, 44 have been assigned CVEs, highlighting substantial security concerns that directly affect Canonical's decision-making process. In response to these findings, particularly related to TOCTOU (Time-of-Check to Time-of-Use) race conditions, Canonical has announced they will continue using GNU implementations of 'cp', 'mv', and 'rm' in Ubuntu 26.04.
The vulnerabilities span across numerous utilities, with several particularly concerning patterns emerging. Many of the identified issues relate to race conditions where the time between checking a file's state and acting upon it creates exploitable windows. For example, CVE-2026-35352 reveals a critical flaw in uutils' 'mkfifo' implementation where the utility creates a FIFO with world-readable permissions before applying the intended permissions via chmod. This creates a window during which an attacker could replace the FIFO with a symbolic link, redirecting the chmod operation to an arbitrary file.
Similarly, CVE-2026-35367 exposes a permissions issue in 'nohup', which creates output files with world-readable permissions rather than the owner-only permissions used by GNU coreutils. This could potentially expose sensitive information in multi-user environments.
The audit also revealed concerning discrepancies in behavior compared to GNU coreutils. CVE-2026-35370 demonstrates how uutils' 'tail' utility handles file replacement differently from GNU's implementation. When a file being monitored with --follow=name is replaced by a symbolic link, GNU tail detects this and reports that the file has been replaced with an untailable symbolic link. In contrast, uutils tail continues to follow the new file, potentially leading to information disclosure if the symlink points to sensitive system files.
Perhaps most troubling are the multiple TOCTOU vulnerabilities affecting file manipulation utilities. CVE-2026-35357 through CVE-2026-35360 all describe race conditions in the 'cp' utility that could allow attackers to bypass security mechanisms or disclose sensitive information. These vulnerabilities stem from the fundamental approach of creating files with default permissions before applying the intended permissions, creating exploitable windows.
The comprehensive list of CVEs reveals several categories of vulnerabilities:
Race conditions: Numerous utilities suffer from TOCTOU vulnerabilities where the time between checking file state and acting upon it creates exploitable windows. This affects utilities like cp, mv, rm, install, and mkfifo.
Permission handling: Several utilities incorrectly handle file permissions, either applying them insecurely or failing to preserve them correctly during operations. This affects mkfifo, nohup, and chown.
Path traversal vulnerabilities: Some utilities fail to properly protect against symlink attacks, allowing attackers to redirect operations to unintended files. This affects chmod, rm, and several other utilities.
Input validation issues: Several utilities incorrectly handle edge cases in input parsing, particularly with non-UTF-8 filenames and special character sequences. This affects comm, sort, ln, and others.
Behavioral discrepancies: Many utilities exhibit different behavior from their GNU counterparts, potentially breaking scripts and workflows that rely on specific behaviors. This affects tail, id, expr, and others.
Canonical's decision to continue using GNU implementations for critical file operations reflects the severity of these vulnerabilities. The Rust rewrite was intended to improve security and reliability, but these findings suggest that the uutils implementation, while promising in concept, may not yet be ready for production use in all scenarios.
The author of the oss-sec post, Collin Funk, a committer to GNU coreutils, provides several concrete examples of these vulnerabilities in action. His analysis suggests that while many issues have been addressed, significant security concerns remain, particularly in race condition handling.
One particularly concerning pattern is the inconsistent handling of security-critical operations across different utilities. Some utilities implement proper race condition mitigation using file descriptors, while others rely on path-based operations that are vulnerable to symlink attacks. This inconsistency suggests that the uutils codebase lacks a unified security model for handling file operations.
The implications of these vulnerabilities extend beyond Ubuntu's decision. If other Linux distributions consider adopting uutils coreutils, they would face similar security assessments. The comprehensive audit results serve as a valuable resource for the broader community evaluating the readiness of uutils for production use.
Looking forward, the uutils project faces significant challenges in addressing these vulnerabilities. The Rust language offers memory safety advantages over C, but these findings demonstrate that memory safety alone does not guarantee secure implementation of complex file operations. The project will need to develop robust patterns for handling race conditions, path validation, and permission management across all utilities.
For Ubuntu, this represents a setback in their "carefully but purposefully oxidising" initiative, but not necessarily a permanent one. By continuing to use GNU implementations for critical operations while maintaining the uutils transition as a long-term goal, Canonical can balance immediate security concerns with their strategic vision for a more modern codebase.
The broader Linux community will be watching closely as the uutils project addresses these vulnerabilities. The success of this rewrite could influence the future direction of coreutils development across distributions, potentially setting new standards for security and reliability in system utilities.
In conclusion, while the uutils coreutils project represents an ambitious and potentially valuable rewrite of essential system utilities, the security vulnerabilities revealed by the Zellic audit demonstrate that significant work remains before it can be considered a drop-in replacement for GNU coreutils in production systems. Canonical's measured approach reflects responsible security practices, and the lessons learned from this audit will undoubtedly benefit both projects as they evolve.
Comments
Please log in or register to join the discussion