Возможность компрометации Nixpkgs и подстановки своего кода в любой пакет была продемонстрирована исследователями безопасности в октябре прошлого года на конференции NixCon и сразу была устранена в инфраструктуре проекта. Тем не менее, подробности о проведённой атаке раскрыты только спустя год. Проблема была связана с использованием в GitHub-репозитории Nixpkgs обработчиков GitHub Actions, привязанных к событию «pull_request_target» и выполняющих автоматизированные проверки при поступлении новых pull-запросов.
В отличие от события «pull_request» в «pull_request_target» обработчикам предоставялется доступ на запись и чтение к сборочному окружению, что требует особого внимания при работе с данными, передаваемыми в pull-запросе. В одном из привязанных к «pull_request_target» обработчиков производилась проверка приведённого в pull-запросе файла «OWNERS», для чего собиралась и вызывалась утитита codeowners-validator:
steps: - uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf with: ref: refs/pull/$/merge path: pr - run: nix-build base/ci -A codeownersValidator - run: result/bin/codeowners-validator env: OWNERS_FILE: pr/ci/OWNERS
Проблема была в том, что в случае ошибки оформления файла OWNERS утилита codeowners-validator выводила содержимое некорректно оформленной строки в стандартный лог, доступный публично. Атака свелась к размещению в pull-запросе символической ссылки с именем OWNERS, ссылающейся на файл «.credentials», в котором в сборочном окружении размещаются учётные данные. Соответственно, обработка данного файла привела к ошибке и выводу в публичный лог первой строки, содержащей токен доступа к репозиторию.

Кроме того, была найдена ещё одна уязвимость в обработчике, выполняющем проверку правил editorconfig.
steps: - name: Get list of changed files from PR run: gh api [...] | jq [ ... ] > "$HOME/changed_files" - uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 with: ref: refs/pull/$/merge - name: Checking EditorConfig run: cat "$HOME/changed_files" | xargs -r editorconfig-checker
В данном случае проблема была в использовании утилиты «xargs» для запуска программы editorconfig-checker с каждым файлом из pull-запроса. Так как имена файлов не проверялись на корректность, атакующий мог разместить в pull-запросе файл со спецсимволами, которые были бы обработаны при запуске утилиты editorconfig-checker как аргументы командной строки. Например, при создании файла «—help» утилита editorconfig-checker вывела бы подсказку об имеющихся опциях.
Источник: http://www.opennet.ru/opennews/art.shtml?num=64059