Aby włączyć do repozytorium pakietów nixpkgs, używanego w dystrybucji NixOS, zaproponowano tryb powtarzalnych kompilacji, pozwalający na wykrywanie przypadków wprowadzenia backdoorów do kodu, przypominających incydent z projektem XZ. Przedstawiona metoda ochrony pozwala na wykrycie modyfikacji w archiwach z kodem źródłowym wydania, które nie występują w repozytoriach z kodem.
Istota metody polega na tym, że kod źródłowy nowej wersji aplikacji jest kompilowany dwa razy — pierwszy raz z kodu pobranego z repozytorium git, a drugi raz z kodu dystrybuowanego w gotowych archiwach. Jeśli uzyskane w wyniku kompilacji pliki binarne się różnią, pojawia się powód do podejrzeń o istnieniu ukrytych modyfikacji w repozytorium lub w archiwum z kodem.
Przypomnijmy, że w przypadku projektu XZ repozytorium z kodem nie zawierało podejrzanych zmian. Tworzące backdoor złośliwe komponenty były dostarczane w plikach używanych w zestawie testowym do weryfikacji poprawności działania rozpakowarki XZ. Backdoor aktywował się na poziomie systemu kompilacji, a sam kod źródłowy XZ pokrywał się z kodem z repozytorium. Aktywujące backdoor makra m4 dla narzędzia Automake były zawarte tylko w gotowym archiwum z kodem i nie występowały w repozytorium.
Backdoor w XZ został wprowadzony przez intruza, który uzyskał status opiekuna w projekcie. Wprowadzenie backdoora zostało natychmiast niezauważone, ponieważ dystrybucje w głównej mierze kompilują pakiety, pobierając kod z gotowych archiwów, ponieważ podczas pobierania kodu do kompilacji można ograniczyć się do jednego sumy kontrolnej do sprawdzenia integralności pliku z archiwum i korzystać z luster. Główna uwaga podczas sprawdzania kodu koncentruje się na analizie zawartości repozytorium, dlatego nieoczywiste różnice w archiwach nie zawsze mogą być od razu wykryte.
Aby uprościć weryfikację zgodności archiwów i zrzutów repozytoriów odpowiadających wydaniom, niektóre projekty open source, takie jak PostgreSQL, wprowadziły system powtarzalnej generacji archiwów. W tym przypadku udostępniane jest narzędzie, które pozwala na własnoręczne zbudowanie archiwum z kodu, które całkowicie odpowiada gotowemu archiwum dostępnym do pobrania. Jeśli niezależnie stworzone archiwum różni się od archiwum dostarczonego przez główny projekt, to oznacza, że repozytorium lub archiwum wzorcowe zostało skompromitowane.
Problem polega na tym, że taka metoda jest stosowana tylko w wyjątkowych przypadkach, podczas gdy wiele projektów nadal włącza do archiwów dodatkowe artefakty, których brakuje w głównym repozytorium, takie jak strony man, dokumentacja, przykłady, skrypty pakowania dla dystrybucji oraz dodatkowe pliki kompilacji. Głównie dzieje się to z powodów historycznych i specyfiki procesu tworzenia wydań. Prosta weryfikacja zgodności zawartości repozytorium i archiwum w tym przypadku nie jest wystarczająca.
Jako rozwiązanie zaproponowano zbieranie plików binarnych wydania, zarówno z repozytorium (na przykład można wykorzystać automatycznie generowane w GitHub archiwum dla tagu wydania), jak i z archiwum przygotowanego przez opiekuna, a następnie porównywanie wyników. Na razie zaproponowano włączenie takiej weryfikacji tylko dla pakietu „xz” jako eksperyment. Jeśli eksperyment powiedzie się, weryfikacja planowana jest również dla innych pakietów w nixpkgs.
Źródło: opennet.ru
