Urgent Security Update: Guix System Patches Critical Vulnerability

A critical security vulnerability has been discovered in the widely-used Guix system, particularly affecting the guix-daemon. This flaw could allow local users to escalate privileges, potentially tampering with the builds’ outputs in multi-user environments.

At the issue’s core lies the guix-daemon’s handling of build outputs, particularly when builds fail. According to the advisory, “guix-daemon has helpfully made the outputs of failed derivation builds available at the same location they were at in the build container.” While this feature has been useful in certain scenarios, it has also introduced a security risk.

An attacker can exploit this mechanism by starting a derivation build that generates a binary with setuid or setgid bits, which grants special privileges. If the build fails, the attacker gains access to the binary, which can then be executed with escalated privileges. The advisory warns, “The attacker or a cooperating user can then execute the binary, gain the privileges, and from there use a combination of signals and procfs to freeze a builder, open any file it has open via /proc/$PID/fd, and overwrite it with whatever it wants.”

This exploit is particularly dangerous on multi-user systems, as it allows the attacker to manipulate builds started by any user, potentially producing compromised outputs for widely-used programs. The advisory notes that this vulnerability also affects successful builds, introducing a small window of opportunity where permissions, ownership, and timestamps have not been canonicalized. This makes the vulnerability even more concerning.

To assist users in determining if their system is vulnerable, a proof-of-concept script has been provided.

(use-modules (guix)
             (srfi srfi-34))

(define maybe-setuid-file
  ;; Attempt to create a setuid file in the store, with one of the build
  ;; users as its owner.
  (computed-file "maybe-setuid-file"
                 #~(begin
                     (call-with-output-file #$output (const #t))
                     (chmod #$output #o6000)

                     ;; Failing causes guix-daemon to copy the output from
                     ;; its temporary location back to the store.
                     (exit 1))))

(with-store store
  (let* ((drv (run-with-store store
                (lower-object maybe-setuid-file)))
         (out (derivation->output-path drv)))
    (guard (c (#t
               (if (zero? (logand #o6000 (stat:perms (stat out))))
                   (format #t "~a is not setuid: your system is not \
vulnerable.~%"
                           out)
                   (format #t "~a is setuid: YOUR SYSTEM IS VULNERABLE.

Run 'guix gc' to remove that file and upgrade.~%"
                           out))))
      (build-things store (list (derivation-file-name drv))))))

By running:

guix repl -- setuid-exposure-vuln-check.scm

The script will inform users if their guix-daemon is vulnerable, making it a crucial tool for system administrators and users alike.

To mitigate this vulnerability, two essential fixes were introduced:

1. Sanitizing Permissions for Failed Builds: Failed build outputs are now sanitized to ensure that any setuid/setgid bits are removed before being moved to the store. This prevents attackers from accessing untrusted binaries.
2. Canonicalizing Permissions for Successful Builds: Successful build outputs are moved to the store only after their permissions have been fully canonicalized, further reducing the attack surface.

These fixes are part of recent commits, and users are urged to upgrade their guix-daemon to these versions. Additionally, running guix gc will help clean up any failed build outputs that may still be present.

The Guix Project has strongly advised all users to upgrade their guix-daemon without delay. The procedure for upgrading varies depending on how Guix is used, but the process is straightforward for most users. Guix System users can upgrade with the following commands:

guix pull
sudo guix system reconfigure /run/current-system/configuration.scm
sudo herd restart guix-daemon

For those using Guix as a package manager on other distributions, the upgrade process involves pulling the latest changes and restarting the guix-daemon service:

sudo --login guix pull
sudo systemctl restart guix-daemon.service

The advisory also mentions the importance of ensuring that daemon sockets are restricted to trusted users, particularly for those using –disable-chroot.

Related Posts:

• BattlEye Vulnerability: “BannleEye” Exploit Allows Arbitrary Banning Users
• Akira Ransomware Exploit CVE-2024-40766 in SonicWall SonicOS