For at inkludere i pakke-repositoriet nixpkgs, der anvendes i NixOS-distributionen, er der foreslået en metode til reproducerbare builds, som gør det muligt at identificere tilfælde af bagdøre i koden, der minder om hændelsen med projektet XZ. Den præsenterede beskyttelsesmetode muliggør opdagelse af ændringer i arkiver med kildetekst for udgivelser, som ikke er til stede i kode-repositorierne.
Essensen af metoden er, at koden for den nye version af applikationen bygges to gange — første gang fra koden, der er hentet fra git-repositoriet, og anden gang fra koden, der distribueres i færdige arkiver. Hvis de opnåede binære filer fra builds er forskellige, er der grund til mistanke om skjulte ændringer i repositoriet eller i arkivfilen med koden.
Det skal bemærkes, at i tilfælde af projektet XZ indeholdt kode-repositoriet ikke mistænkelige ændringer. De bagdørs-malicious komponenter blev leveret i filer brugt i test-sættet til at kontrollere korrektheden af XZ-dekompressoren. Bagdøren blev aktiveret på niveauet for byggesystemet, mens selve koden fra XZ svarede til koden fra repositoriet. De aktiverende bagdørs m4-makroer til Automake-værktøjet blev kun inkluderet i det færdige arkiv med koden og var ikke til stede i repositoriet.
Bagdøren i XZ blev indført af en angriber, der opnåede status som vedligeholder i projektet. Implantationen af bagdøren blev ikke opdaget straks, da distributioner hovedsageligt bygger pakker ved at hente koden fra færdige arkiver, da man ved hentning af koden til bygning kan nøjes med en kontrolsum til at verificere filens integritet for arkivet og bruge spejle. Den primære opmærksomhed ved kontrol af koden er fokuseret på analysen af indholdet af repositoriet, så ikke-opfattelige forskelle i arkiverne kan ikke altid straks opdages.
For easier verification of archive files and repository snapshots corresponding to releases, some open projects, like PostgreSQL, have adopted a reproducible archive generation system. In this case, tools are provided that allow you to compile your archive from the code, fully matching the ready-to-download archive. If the independently created archive differs from the archive provided by the main project, this indicates a compromise of the repository or reference archive.
The problem is that such a method is only practiced in certain cases, while many projects continue to include additional artifacts in archives that are not present in the main repository, such as man pages, documentation, examples, package build scripts for distributions, and additional build files. This mainly occurs due to historical reasons and the peculiarities of the release formation processes. A simple check of the repository content against the archive is not suitable in this case.
As a solution, it is proposed to generate release binary files both from the repository (for example, using the automatically generated GitHub archive for the release tag) and from the archive prepared by the maintainer, then comparing the results. For now, such a check has only been suggested for the 'xz' package. If the experiment proves successful, similar checks are planned for use in other packages in nixpkgs.
Kilde: opennet.ru
