В NixOS предложен метод защиты от подстановки бэкдоров, таких как в XZ

Для включения в репозиторий пакетов nixpkgs, применяемый в дистрибутиве NixOS, предложен режим повторяемых сборок, позволяющий выявлять случаи внедрения в код бэкдоров, напоминающие инцидент с проектом XZ. Представленный метод защиты позволяет обнаружить модификации в архивах с исходным кодом релиза, отсутствующие в репозиториях с кодом.

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

Напомним, что в случае с проектом XZ репозиторий с кодом не содержал подозрительных изменений. Образующие бэкдор вредоносные компоненты поставлялись внутри файлов, используемых в тестовом наборе для проверки корректности работы распаковщика XZ. Бэкдор активировался на уровне системы сборки, а сам исходный код XZ совпадал с кодом из репозитория. Активирующие бэкдор m4-макросы для инструментария Automake были включены только в готовый архив с кодом и отсутствовали в репозитории.

Бэкдор в XZ был внедрён злоумышленником, добившимся получения статуса сопровождающего в проекте. Внедрение бэкдора оказалось сразу не замечено из-за того, что дистрибутивы в основном собирают пакеты, загружая код из готовых архивов, так как при загрузке кода для сборки можно обойтись одной контрольной суммой для проверки целостности файла с архивом и использовать зеркала. Основное внимание при проверке кода сосредоточено на анализе содержимого репозитория, поэтому неочевидные отличия в архивах не всегда могут быть сразу выявлены.

Для упрощения проверки соответствия файлов-архивов и срезов репозитория, соответствующих релизам, некоторые открытые проекты, такие как PostgreSQL, ввели в обиход систему повторяемой генерации архивов. В данном случае предоставляется инструментарий, позволяющий самостоятельно собрать из кода свой архив, полностью соответствующий готовому архиву, доступному для загрузки. Если независимо созданный архив и архив, предоставляемый основным проектом, будут отличаться — имеет место компрометация репозитория или эталонного архива.

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

Как выход предложено собирать бинарные файлы релиза, как из репозитория (например, можно использовать автоматически генерируемый в GitHub архив для релизного тега), так и из архива, подготовленного сопровождающим, сравнивая затем результат. В качестве эксперимента включение подобной проверки пока предложено только для пакета «xz». Если эксперимент окажется удачным проверки планируют использовать и в других пакетах в nixpkgs.

Источник: opennet.ru