Критическая уязвимость в Nix позволяет злоумышленникам получить полный контроль над системой

vulnerability

В экосистеме свободного программного обеспечения обнаружена новая критическая уязвимость, затрагивающая популярный пакетный менеджер Nix и, как следствие, дистрибутив NixOS. Проблема, получившая идентификатор CVE-2026-39860 и оценку 9.0 по шкале CVSS, позволяет злоумышленнику с правами на отправку заданий сборки фоновому процессу Nix перезаписывать любые файлы в системе. В конфигурациях NixOS и многопользовательских установках этот фоновый процесс, известный как Nix daemon, по умолчанию выполняется с привилегиями суперпользователя (root), что превращает уязвимость в полноценный механизм повышения привилегий и захвата контроля над всей операционной системой. Особую тревогу вызывает тот факт, что данная брешь в безопасности является следствием некорректного исправления другой уязвимости, CVE-2024-27297, устранённой в прошлом году.

Уязвимость CVE-2026-39860

Проблема затрагивает практически все актуальные версии Nix, начиная с релиза 2.21, а также патченные версии 2.18.2, 2.19.4 и 2.20.5, выпущенные ранее. Уязвимыми являются все стандартные конфигурации NixOS, а также любые системы, где разрешена сборка ненадёжных производных (untrusted derivations). С технической точки зрения, эксплуатация становится возможной из-за ошибки в механизме изоляции сборочного окружения. Злоумышленник может подготовить специальный пакет, который в процессе сборки подменяет символической ссылкой один из внутренних каталогов изолированной среды, предназначенный для записи результата сборки. В результате, когда фоновый процесс Nix с правами root попытается записать туда данные, они будут перенаправлены по символической ссылке в произвольное место файловой системы, например, в критически важный системный файл вроде "/etc/shadow" или "/etc/sudoers". Это, в свою очередь, открывает путь для эскалации привилегий и полного компрометирования хоста.

Важно отметить, что уязвимость проявляется только в средах с включённой изоляцией сборки на Linux. Пользователи macOS, даже с активной песочницей, не подвержены риску. Между тем, разработчики дистрибутива Lix, активного форка Nix, заявили, что их пользователи также не затронуты проблемой, поскольку кодовая база проекта уже содержала необходимые защитные механизмы. Для устранения угрозы команда сопровождения Nix выпустила серию патчей для всех поддерживаемых веток. Безопасными теперь считаются версии 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3 и 2.28.6. Обновления уже интегрируются в основные репозитории пакетов, такие как nixpkgs, для нестабильной ветки и стабильного релиза 25.11.

Примечательно, что исправления для версий 2.31 и выше включают не только заплатку для CVE-2026-39860, но и дополнительные меры защиты. Эти меры призваны предотвратить возможность взаимодействия между различными изолированными средами сборки, так называемыми производными с фиксированным выводом (fixed-output derivations). Без таких дополнительных барьеров эти среды могли бы потенциально обмениваться файловыми дескрипторами и данными, создавая новые векторы для атак, даже после закрытия основной уязвимости. Данный инцидент в очередной раз демонстрирует, насколько сложным является корректное построение безопасных систем изоляции, и как попытка исправить одну уязвимость может непреднамеренно создать другую, возможно, даже более опасную.

Для системных администраторов и DevOps-инженеров, использующих Nix и NixOS в production-средах, эта новость служит жёстким напоминанием о необходимости строгого контроля за обновлениями инфраструктурного программного обеспечения. По умолчанию в NixOS все пользователи, имеющие доступ к системе, могут отправлять задачи на сборку фоновому процессу. В контексте данной уязвимости это означает, что любой скомпрометированный аккаунт или вредоносный пакет в цепочке сборки может стать отправной точкой для полного захвата сервера. Поэтому, помимо незамедлительного применения патчей, стоит пересмотреть политики безопасности, такие как настройка "allowed-users" в конфигурации Nix, чтобы ограничить круг лиц, имеющих право инициировать сборки. Этот случай также подчёркивает важность многоуровневой защиты: даже в системах с продвинутой изоляцией процессов критически важные серверы должны быть дополнительно сегментированы и находиться под постоянным мониторингом на предмет аномальной активности.

Ссылки

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