Почему доверие к сборке может быть опаснее исходников

Кен Томпсон в 1984 году показал жуткую вещь: можно модифицировать компилятор так, чтобы он встраивал закладку в любую программу и воспроизводил её в новых версиях самого себя. Долгое время это считалось почти чисто теоретической угрозой — и вот теперь новая статья на arXiv ломает это спокойствие: аналогичную атаку можно провернуть без единой модификации компилятора, через утилиту, которая вообще не генерирует код.

Как это вообще возможно

Обычная логика безопасности в дистрибутивах проста: если ты контролируешь исходный код, значит контролируешь и результат. Собираешь софт из исходников — получаешь чистый бинарник. Но атака работает не на уровне исходников, а на уровне уже скомпилированных файлов.

Конкретно речь идёт о GNU strip — утилите, которая удаляет отладочную информацию из готовых программ. Она не читает исходники и не создаёт код, а просто обрабатывает уже собранные исполняемые файлы. И именно в этот процесс можно встроить закладку: когда strip обрабатывает бинарник, он незаметно добавляет вредоносный код, а заражённый бинарник продолжает работать как ни в чём не бывало.

БИНАРНЫЙ СИД
─────────────
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Заражённый  │────▶│  Новые пакеты │────▶│  Установщик  │
│    strip     │     │  содержат    │     │  полностью   │
│              │     │  закладку    │     │   заражён   │
└──────────────┘     └──────────────┘     └──────────────┘
       │                                        │
       ▼                                        ▼
  Распространение                          Финальный
  через поколения                         результат

Цепочка доверия под ударом

В NixOS и его системе сборки nixpkgs есть механизм bootstrap — минимальный набор бинарных файлов, с которого начинается сборка всей системы. Исследователи взяли один заражённый бинарник strip и поместили его в эту точку входа. Дальше цепочка сработала сама: каждый новый strip, собранный в этой среде, получал закладку, а каждый бинарник, обработанный этим strip, тоже заражался.

Финальный результат — полноценный графический установщик NixOS, который собирается без ошибок, но при этом открывает атакующему произвольный доступ. Никакие исходники не изменены, компиляторы чистые, а результат уже скомпрометирован.

СЛОИ ЗАЩИТЫ
────────────
┌─────────────────────────────────────────────────────┐
│  1. Независимые сборки                              │
├─────────────────────────────────────────────────────┤
│  2. Проверка toolchain отдельными аудиторами        │
├─────────────────────────────────────────────────────┤
│  3. Двоичная сверка через Reproducible Builds       │
├─────────────────────────────────────────────────────┤
│  4. Разделение доверенных контуров (compartments)   │
└─────────────────────────────────────────────────────┘

Почему это не теоретическая угроза

Первый уровень проблемы — доверие к toolchain. Мы привыкли думать, что открытые исходники и их проверка решают всё. Но сборочные утилиты тоже входят в цепочку доверия, и контролировать их сложнее, чем кажется.

Второй уровень — воспроизводимость сборок. Проект Reproducible Builds добивается того, чтобы из одинаковых исходников получались идентичные бинарники. Но если закладка живёт в инструменте обработки бинарников, проблема уже не в исходниках, а в самой сборочной среде.

Третий уровень — масштаб. Исследование показало атаку на одном дистрибутиве, но методология применима везде, где есть бинарные сиды и цепочка пересборки. А это почти любой дистрибутив Linux.

Практический вывод

Независимые сборки полезны там, где одни и те же исходники собирают разные люди на разной инфраструктуре, а затем сравнивают результаты. Если результаты расходятся — значит, в цепочке есть проблема.

Проверка toolchain должна включать аудит не только исходников, но и сборочной среды. Бинарные артефакты, участвующие в сборке, нужно проверять так же тщательно, как и конечный софт.

Reproducible Builds — это не академическая абстракция, а практический инструмент. Если бинарник можно воспроизвести из исходников, закладка в сборочной среде станет заметной.

Моя оценка

Статья важная, но не революционная по идее: Кен Томпсон описал этот вектор атаки сорок лет назад. Новизна здесь в том, что для атаки не нужен модифицированный компилятор — достаточно бинарной манипуляции.

Главный вывод для меня такой: защита open source — это не только про исходный код. Бинарные сиды, сборочные инструменты и инфраструктура сборки тоже являются точками доверия, которые нужно контролировать. И делать это сложнее, чем просто смотреть исходники на GitHub.

Для мейнтейнеров дистрибутивов и CI/CD-систем эта работа особенно полезна. Для обычных пользователей вывод неприятный, но без паники: это демонстрация уязвимости, а не описание активно эксплуатируемой атаки.

Ссылки

• Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation — оригинальная статья на arXiv
• Reproducible Builds — проект независимой верификации бинарников