Команда безопасности Rust (Rust Security Response Team) была уведомлена о том, что Miri сохраняет все переменные окружения в директорию target/, что приводит к сохранению секретных данных в кэшах.
Хотя сама по себе эта особенность не обязательно является уязвимостью, в сочетании с поведением кэширования GitHub Actions она может привести к тому, что секреты станут доступны в Pull Request (PR).
Обзор
GitHub Actions позволяет кэшировать директории между запусками. Типичные настройки разрешают запускам CI в ветке main (и других ветках) записывать данные в кэш, а PR могут только читать из кэша (что предотвращает отравление кэша). Проекты на Rust обычно ускоряют CI, кэшируя бинарные файлы, собранные с помощью cargo install, а иногда и содержимое target/.
CI для PR может быть запущен любым человеком, способным открывать PR в вашем репозитории. GitHub требует одобрения мейнтейнера для первого PR, но последующие PR будут перезапускать CI при каждом пуше. Любой, кто ранее закоммитил изменения, может запустить CI, извлечь информацию из кэшированной директории target/, а затем замести следы, отправив в PR второй коммит.
GitHub иногда скрывает перезаписанные коммиты в своем интерфейсе, что затрудняет обнаружение такого рода атак. Логи запуска CI и перезаписанные коммиты также удаляются через несколько месяцев.
При вызове cargo miri для Miri требуется сохранять между запусками переменные окружения, необходимые для сборки1. Текущий код для этого сохраняет все переменные окружения в target/. Это, разумеется, сохраняется при кэшировании target/.
Если ваше окружение содержало секреты, теперь они могут быть доступны для PR через кэш.
Наше исправление
Наше краткосрочное исправление заключается в том, чтобы заставить Miri сохранять только переменные окружения CARGO_* (за исключением CARGO_*_TOKEN) и OUT_DIR. В более отдаленной перспективе Miri и cargo могут найти лучшие способы информирования Miri о нужном списке переменных окружения. Обратите внимание, что этот патч может быть еще недоступен в версии nightly.
Мы также провели сканирование экосистемы репозиториев на GitHub и выявили 1 репозиторий с этой проблемой и 7 репозиториев, которые не кажутся уязвимыми, но которым всё равно следует проявить осторожность. Мы связались с их мейнтейнерами.
Затронут ли меня этот вопрос?
Вероятно, наше сканирование было несовершенным, поэтому мы рекомендуем вам проверить собственные настройки GitHub Actions, если вы используете Miri.
Вы уязвимы, если:
- Вы запускаете cargo miri в CI
- Шаг, запускающий cargo miri, имеет доступ к секретам в качестве переменных окружения: путем передачи их в сам шаг в качестве переменной окружения, путем их установки в секции env для воркфлоу, путем передачи их на предыдущий шаг, который каким-то образом сохраняет их в окружении
- Путем передачи их в сам шаг в качестве переменной окружения
- Путем установки в секции env для воркфлоу
- Путем передачи их на предыдущий шаг, который каким-то образом сохраняет их в окружении
- Используемый воркфлоу кэширует целевую директорию (target), что обычно делается с помощью actions/cache или swatinem/rust-cache
- Кэш доступен для PR (что является распространенным и часто предполагаемым сценарием использования)
Возможные быстрые исправления включают в себя:
- Отключение кэша для этого задания (job).
- Ограничение секретов рамками шагов в этом задании, которые не вызывают Miri.
- Временное отключение Miri.
После этого, пожалуйста, очистите кэш. Рассмотрите возможность ротации любых секретов, которые могли утечь.
В релизе Miri из предстоящей версии nightly (2026-09-22) этой проблемы больше не будет.
Даже если вы не используете Miri, убедитесь, что задания, имеющие право записывать данные в публичные кэши, не имеют доступа к секретам. Многие инструменты не имеют специальной обработки для секретов и предполагают, что все окружение может быть записано в файловую систему.
Модель угроз
Мы считаем плохой практикой использование кэша, в который могут легко попасть секреты.
При кэшировании target/ стоит убедиться, что входные данные для процессов, создающих target/ (всего, что вызывает cargo), не имеют доступа к секретам. Как правило, стандартные подкоманды сборки и тестирования cargo редко нуждаются в каких-либо секретах или токенах2, поэтому здесь в основном речь идет о том, чтобы соблюдать осторожность и не допускать экспонирования секретов в качестве переменных окружения для всего задания.
Cargo / Miri / Rust не гарантируют защиту переменных окружения от копирования в target/. Хотя мы рассматриваем это как проблему безопасности и выпускаем патч из соображений перестраховки, в общем случае рассчитывать на это не стоит. Помимо официальных инструментов Rust, сценарии сборки могут выполнять действия, которые приводят к сохранению окружения в артефактах компиляции.
Благодарности
Спасибо Предрагу Груевски (Predrag Gruevski) из OpenAI за сообщение об этой проблеме. Кроме того, сканирование экосистемы проводилось с использованием доступа к Codex и кредитов, предоставленных OpenAI, за что мы также выражаем им благодарность.
Триаж и устранение уязвимости выполнялись следующими участниками: Маниш Горегаокар (Manish Goregaokar), Ральф Юнг (Ralf Jung), Бен Кимок (Ben Kimock), Вэйхан Ло (Weihang Lo), Джейкоб Финкельман (Jacob Finkelman), Вальтер Пирс (Walter Pearce), Джош Стоун (Josh Stone) и Марк Руссков (Mark Rousskov).
- Miri вызывается несколько раз с помощью cargo miri по сложным причинам ↩
Miri вызывается несколько раз с помощью cargo miri по сложным причинам ↩
- Теоретически это может возникнуть из-за скриптов сборки, считывающих данные из сети ↩
Теоретически это может возникнуть из-за скриптов сборки, считывающих данные из сети ↩