Recent vulnerabilities have been discovered in the Guix package manager, specifically in the implementation of the internal “guix substitute” command. This command is automatically invoked by the background guix-daemon process during package installation operations. Its purpose is to download pre-assembled binary packages from external servers while verifying their integrity using a digital signature. The most critical vulnerability allows for remote code execution on the user’s system who has the necessary rights under which the guix-daemon process is running.
This vulnerability affects all configurations with the guix-daemon process, whether it is running with root privileges or as an unprivileged user. Exploiting the vulnerability only requires an attempt to download binary packages from a server controlled by the attacker. The malicious server does not need to be explicitly designated in user settings and can be identified using the “–discover” option, enabling server substitution during a MITM attack. In configurations where the guix-daemon is running with elevated privileges, a local user could launch an attack by connecting to the background process via a Unix socket, which is available to all users by default.
The vulnerability lies in the “restore-file” handler, utilized for unpacking packages during download without waiting for them to fully download or verifying the downloaded archive with a digital signature. The issue arises from a lack of validation for characters like “.”, “/”, and “..” in file paths within the archive. By manipulating file names in the archive, an attacker can write arbitrary files to any part of the file system where guix-daemon has permissions.
To execute code on the system, attackers could add a script like “~/.bashrc” or modify the ~/.ssh/authorized_keys file with SSH keys. If guix-daemon runs as root on a multi-user system, attackers could overwrite system scripts or the password file.
The possibility of creating fake servers to distribute malicious packages is due to the fact that the process for downloading metadata about binary packages did not verify the server certificate, assuming the metadata was digitally signed. However, the signature did not encompass the URL for downloading the package, enabling its substitution without compromising metadata integrity. Although the fake package would ultimately be rejected during the verification process, the issue with special characters in file names arises during unpacking.