В NixOS е предложен метод за защита от внедряване на бекдори, подобно на XZ.

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

Същността на метода е, че изходният код на новата версия на приложението се компилира два пъти – първият път от кода, изтеглен от git репозиторий, а вторият път от кода, разпространяван в готови архиви. Ако получените в резултат на компилацията бинарни файлове се различават, това е причина за съмнения в наличието на скрити модификации в репозитория или в архивния файл с код.

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

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

С целта да се улесни проверката на съответствието на архивираните файлове и изрезките на хранилището, отговарящи на релизите, някои открити проекти, като PostgreSQL, въведоха система за повторно генериране на архиви. В този случай се предоставя инструментариум, който позволява самостоятелно да се създаде архив от кода, напълно съответстващ на готовия архив, достъпен за изтегляне. Ако независимо създаденият архив и архивът, предоставен от основния проект, се различават, то това е индикатор за компрометиране на хранилището или еталонния архив.

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

Както решение, предложено е да се събират бинарни файлове на релиза както от хранилището (например, може да се използва автоматично генерирания в GitHub архив за релизния таг), така и от архива, подготвен от поддръжника, след което да се сравнява резултатът. Като експеримент, включването на подобна проверка за момента е предложено само за пакета "xz". Ако експериментът се окаже успешен, проверки планират да се използват и в други пакети в nixpkgs.

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