Команда реагирования на угрозы безопасности Rust (Rust Security Response Team) получила уведомление о том, что Miri сохраняет все переменные окружения в target/, из-за чего секреты могут оставаться в кэше.
Хотя само по себе это не обязательно является уязвимостью, в сочетании с поведением кэширования GitHub Actions это может привести к раскрытию секретов для 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 должен сохранять релевантные для сборки переменные окружения между запусками. Текущий код делает это, сохраняя all environment variables to 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 directory), что обычно делается с помощью actions/cache или swatinem/rust-cache
- Кэш доступен для PR (что является обычным и часто предполагаемым сценарием использования)
Возможные быстрые исправления включают в себя:
- Отключение кэша для этого задания.
- Ограничение области видимости секретов только теми шагами в этом задании, которые не вызывают Miri.
- Временное отключение Miri.
После этого, пожалуйста, очистите кэш. Рассмотрите возможность ротации любых секретов, которые могли утечь.
В релизе Miri в предстоящей версии nightly (2026-09-22) этой проблемы больше не будет.
Даже если вы не запускаете Miri, убедитесь, что задания, которые могут записывать данные в публичные кэши, не имеют доступа к секретам. Многие инструменты не имеют специальной обработки для секретов и предполагают, что все окружение может быть записано в файловую систему.
Модель угроз
Мы считаем плохой практикой иметь кэш, который может быть легко скомпрометирован секретами.
При кэшировании target/ стоит убедиться, что входные данные для процессов, создающих target/ (всего, что вызывает cargo), не имеют доступа к секретам. Как правило, стандартным подкомандам сборки/тестирования cargo редко требуются какие-либо секреты или токены, поэтому в основном это вопрос аккуратности в отношении того, чтобы секреты не были доступны в качестве переменных окружения для всего задания.
Cargo/Miri/Rust не гарантируют, что переменные окружения будут защищены от копирования в target/. Хотя мы рассматриваем это как проблему безопасности и устраняем ее из соображений перестраховки, вам не следует полагаться на это в целом. Помимо официальных инструментов Rust, сценарии сборки (build scripts) могут выполнять действия, которые приводят к сохранению окружения в артефактах компиляции.
Благодарности
Спасибо Предрагу Груевски (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 по сложным причинам ↩
- Теоретически это может проявиться в сценариях сборки, читающих данные из сети ↩
Теоретически это может проявиться в сценариях сборки, читающих данные из сети ↩
