Critical GNU Guix Vulnerabilities Let Attackers Elevate Privileges

Key Takeaways

• Four critical vulnerabilities have been discovered in GNU Guix, impacting its package substitution and channel management functionalities.
• Three flaws in guix substitute could lead to remote privilege escalation, data corruption, and local file disclosure, while a fourth affects guix pull and guix time-machine.
• The most severe vulnerability allows arbitrary file writes on systems, particularly those where guix-daemon runs with root privileges.
• These issues affect all Guix systems, regardless of daemon configuration, though the impact is more significant with root privileges.
• Patches have been released, and users are urged to upgrade Guix and guix-daemon to the specified commit or later versions immediately.

Critical Flaws Discovered in GNU Guix Lead to Privilege Escalation and Data Corruption

Security researchers have uncovered four significant vulnerabilities within GNU Guix, a functional package manager and operating system distribution. These flaws primarily impact the system’s package substitution mechanism and channel management, potentially leading to severe consequences such as remote privilege escalation, data integrity compromise, and unauthorized local file access.

The identified security weaknesses include three distinct issues within the guix substitute utility, which is responsible for fetching pre-built binaries. A separate, fourth vulnerability affects both guix pull and guix time-machine, components used for managing software channels and historical configurations. While all Guix systems are susceptible, the severity of potential attacks escalates significantly when the guix-daemon operates with root privileges, opening avenues for attackers to manipulate critical system files, including /etc/passwd.

Deep Dive into GNU Guix Vulnerabilities

The most critical of the recently disclosed flaws resides in the restore-file procedure, a core function for unpacking binary substitutes. Historically, Guix would commence the extraction of substitute archives even before their complete hash verification. This operational oversight created a window for exploitation. A malicious substitute server, or an attacker performing a man-in-the-middle (MITM) attack, could inject a specially crafted archive during the download process. This archive could then write arbitrary files to locations accessible by the daemon user, bypassing integrity checks.

Crucially, this attack vector does not necessitate the compromise of an official Guix server. Any configured substitute server, including those automatically discovered via the daemon’s --discover option, could deliver malicious payloads. Furthermore, relying solely on HTTPS encryption does not mitigate this risk entirely, as the vulnerable narinfo metadata-fetching process failed to securely link the substitute download URL with signed metadata.

A second vulnerability within the substitute mechanism permits a malicious source to present valid metadata for one store item when Guix requests another. This manipulation could trick the package manager into deploying an unintended, albeit signed, store item, potentially forcing systems to install outdated or otherwise insecure software versions.

The third guix substitute flaw involves the handling of file:// URLs. Unauthorized local clients capable of interacting with the default guix-daemon socket could coerce the daemon into reading local files through these URIs. Should a readable file trigger an error during narinfo parsing, its contents might inadvertently appear within an error backtrace returned to the client, thereby exposing sensitive information accessible to the daemon account.

Separately, a path traversal vulnerability was identified in guix pull and guix time-machine, specifically within their channel authentication caching. An attacker controlling a channel file could craft a malicious channel name to create or overwrite files writable by the user executing the command. While the most immediate practical impact is assessed as a denial-of-service, the project acknowledges the potential for more sophisticated exploitation in specific environmental configurations.

The Guix developers fixed the issues through a series of commits integrated into pull request #9665. Users are strongly advised to upgrade both guix and guix-daemon to commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c or any subsequent version. For systems that are particularly exposed, administrators should consider using the --no-substitutes option during the upgrade process, weighing this against the complexities of local build compilation. Guix has also provided a Scheme-based checker to help users determine if their systems remain vulnerable to these four identified flaws.

What You Should Do

• Immediately upgrade your Guix installation and guix-daemon to commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c or a newer version.
• For critical or exposed systems, consider using the --no-substitutes flag during the upgrade process to prevent potential exploitation during the update, understanding this might require local compilation.
• Utilize the Scheme-based checker provided by Guix to confirm your system is no longer vulnerable after applying updates.
• Regularly monitor the official Guix blog and security announcements for further updates and best practices.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.