Критические уязвимости в Guix: удалённое выполнение кода и подмена пакетов

guix

В пакетном менеджере Guix устранено четыре уязвимости, наиболее критическая из которых позволяет удалённо выполнить код с правами фонового процесса guix-daemon. Проблемы обнаружены в реализации внутренней команды "guix substitute", а также в командах "guix pull" и "guix time-machine". Разработчики проекта выпустили патч и настоятельно рекомендуют обновить guix и guix-daemon немедленно.

Уязвимость восстановления файлов (restore-file)

Наиболее опасная проблема затрагивает процедуру restore-file в модуле (guix serialization). Она используется для извлечения бинарных архивов (нарративов) по мере их загрузки, не дожидаясь полной загрузки и проверки хеша по цифровой подписи. Обработчик не проверял наличие в файловых путях внутри архива символов ".", "/" и "..". Злоумышленник, контролирующий сервер, с которого загружается пакет, может подставить в архив пути вида "../../../../tmp/evil". В результате вредоносный файл будет записан в произвольную область файловой системы, куда разрешена запись процессу guix-daemon.

Если guix-daemon запущен с правами root, атакующий может перезаписать, например, /etc/passwd или добавить автозапускаемый скрипт для любого пользователя (через ~/.bashrc или ~/.ssh/authorized_keys). В конфигурациях с непривилегированным daemon возможности ограничены правами этого пользователя, но локальный взлом все еще возможен.

Атака требует лишь попытки загрузки любого бинарного пакета с сервера, подконтрольного злоумышленнику. Такой сервер может быть назначен явно в настройках, определён автоматически через опцию "--discover" или подставлен в ходе MITM-атаки, даже если используются HTTPS-ссылки: проверка сертификата выполняется только для URL, указанного в метаданных, а не для оригинала.

Процедура restore-file также задействована в командах "guix offload", "guix archive --extract" и "guix challenge". Они все уязвимы при обработке непроверенных входных данных.

Подмена метаданных пакета

В процедуре fetch-narinfos, отвечающей за получение метаданных о доступных бинарных пакетах, отсутствовала верификация того, что возвращённая информация соответствует запрошенному пакету. Сервер может подменить метаданные: выдать narinfo от одного пакета вместо другого. Поскольку URL для загрузки нарратива не является частью данных, заверенных подписью, злоумышленник может перенаправить загрузку на любой сервер. Хотя сам нарратив будет отклонён при несовпадении хеша, к тому моменту он уже будет распакован - и сработает уязвимость restore-file.

Минимальный ущерб от этой уязвимости - возможность заставить систему использовать устаревшие и потенциально уязвимые версии пакетов, если нужный пакет отсутствует, а старый есть у авторизованного сервера.

Раскрытие содержимого файлов через file:// URI

В команде "guix substitute" допускалось использование URI схемы "file://" как для указания серверов подстановок, так и для URL нарративов внутри метаданных. Если локальный пользователь передаёт запрос с таким URI, например "--substitute-urls file:///etc/shadow", то guix-daemon, проверяя файл, может прочитать его содержимое. Если строка не является корректным narinfo, генерируется ошибка, в текст которой попадает первая строка прочитанного файла. Так sensitive-данные (пароли, ключи) могут быть раскрыты любому локальному пользователю.

Более того, при использовании файлов в /proc/PID/fd это может позволить вмешаться в чтение данных любым процессом, доступным пользователю daemon.

Запись файлов через имя канала в guix pull и guix time-machine

Процедура authenticate-channel, используемая для верификации каналов при выполнении "guix pull" и "guix time-machine", вычисляла ключ кеша из имени канала. Если имя канала содержит конструкцию вида "../../../../newfile", то в качестве имени файла для кеша использовался путь, выходящий за пределы директории кеша. Это приводило к созданию или перезаписи файла в произвольном месте, доступном пользователю для записи. Однако содержимое файла ограничено синтаксисом Scheme-списка строк, поэтому практический ущерб сводится к DoS-атаке. Тем не менее, при умелой работе с псевдо-файловой системой /proc возможно добиться более серьёзных последствий.

Исправления

Разработчики выпустили серию из 11 коммитов, начиная с ed0a9721f8a20d6ddcf6a0495302f502b3f7bb17 и заканчивая 2ef8ed9f0df53bddf14bdecc2ea48c2d233213cc. Пользователям необходимо обновиться до коммита 897832f374dcdc9eeaf19d01e70b9a92fccfc68c или более позднего.

Для устранения уязвимости restore-file код был ужесточён: теперь restore-file отвергает недопустимые имена записей архива (пустые, ".", "..", содержащие слеш или нуль-байт, а также неуникальные или идущие не по порядку). Кроме того, процедуры записи файлов теперь создают целевой файл заново и не следуют символическим ссылкам.

Процедура fetch-narinfos изменена так, что возвращаемый результат проверяется на соответствие запрошенному. В команде "guix substitute" проверяется, что все URL подстановок из ненадёжных источников не используют схему file://, а также что URL нарративов в narinfo тоже не file:// (за исключением тестового режима). Дополнительно архивы теперь распаковываются во временную директорию и перемещаются в хранилище только после проверки хеша.

Уязвимость в authenticate-channel устранена изменением способа вычисления ключа кеша: теперь он выводится из идентификатора вводного коммита (introductory commit) - безопасной шестнадцатеричной строки. Все точки в ключе заменяются на дефис, чтобы избежать выхода за пределы директории кеша.

Временные меры

До установки обновления можно заблокировать наиболее опасные атаки, отключив использование бинарных подстановок опцией "--no-substitutes" во всех командах guix. Однако это не защищает от локальной атаки, для которой необходимо подключение к сокету guix-daemon (по умолчанию доступно любому пользователю). Для уязвимости в guix pull и guix time-machine безопаснее не запускать эти команды с непроверенными файлами каналов.

Контекст

Проблемы были выявлены в ходе внутреннего аудита после обращения Йорга Тальхайма из проекта Nix, который обнаружил уязвимую логику restore-file. С марта по июнь 2026 года исследователи из команды безопасности Guix и сообщества нашли остальные уязвимости. Все они закрыты в едином патче. Хотя CVSS-оценки пока не присвоены, разработчики считают угрозу удалённого выполнения кода критической.

Всем пользователям Guix - как на системе Guix, так и на других дистрибутивах с установленным Guix - следует как можно скорее выполнить обновление согласно инструкциям проекта. После переконфигурации системы или обновления пакета необходимо перезапустить guix-daemon.

Ссылки

Комментарии: 0