I NixOS föreslås en metod för att skydda mot substitutionsbakdörrar, såsom i XZ.

För att inkludera paketet nixpkgs i NixOS-distributionen har en metod för reproducerbara byggen föreslagits, vilket gör det möjligt att upptäcka fall av bakdörrar i koden, liknande incidenten med projektet XZ. Den föreslagna skyddsmekanismen gör det möjligt att upptäcka modifieringar i arkiv med källkoden för releasen som saknas i kodarkiven.

Metodens kärna är att den nya versionens källkod byggs två gånger — först från koden som laddas ned från git-repositoriet, och andra gången från koden som distribueras i färdiga arkiv. Om de binära filer som genererats från byggena skiljer sig åt, uppstår mistankar om dolda modifieringar i repositoriet eller i arkivfilen med koden.

Vi påminner om att i fallet med projektet XZ innehöll kodarkivet inga misstänkta förändringar. De bakdörrsframkallande skadliga komponenterna levererades i filer som användes i testsviten för att kontrollera korrektheten av XZ:s dekompressor. Bakdörren aktiverades på nivån för byggsystemet, och själva koden för XZ överensstämde med koden i repositoriet. Bakdörren aktiverande m4-makron för Automake-verktygen var endast inkluderade i det färdiga arkivet med koden och saknades i repositoriet.

Bakdörren i XZ infördes av en angripare som lyckades få status som underhållare i projektet. Införandet av bakdörren gick omedelbart obemärkt förbi eftersom distributioner huvudsakligen bygger paket genom att ladda ner kod från färdiga arkiv, då det vid kodlagret kan räcka med en kontrollsumma för att verifiera filens integritet med arkivet och använda speglar. Huvudfokuset vid granskningen av koden ligger på analysen av innehållet i repositoriet, därför kan inte alltid oaktade skillnader i arkiven omedelbart upptäckas.

För att förenkla kontrollen av överensstämmelsen mellan arkivfiler och repository-cut-offs som motsvarar releaser, har vissa öppna projekt, såsom PostgreSQL, infört ett system för reproducerbar generering av arkiv. I det här fallet tillhandahålls verktyg som gör det möjligt att själv skapa ett arkiv från koden som helt överensstämmer med det färdiga arkivet som finns för nedladdning. Om det självständigt skapade arkivet och arkivet som tillhandahålls av huvudprojektet skiljer sig åt, är det en indikator på kompromettering av repositoryt eller referensarkivet.

Problemet är att en sådan metod endast tillämpas i vissa fall, medan många projekt fortsätter att inkludera ytterligare artefakter i arkiv som saknas i huvudrepositoryt, såsom man-sidor, dokumentation, exempel, skript för att skapa paket för distributioner och ytterligare byggfiler. Detta beror främst på historiska skäl och särdrag i release-processerna. En enkel jämförelse av innehållet i repositoryt och arkivet är i detta fall inte tillräcklig.

Som en lösning föreslås att samla binära filer för release, både från repositoryt (till exempel kan det automatiskt genererade arkivet i GitHub för release-taggen användas) och från arkivet som förberetts av underhållaren, för att sedan jämföra resultaten. Som ett experiment har en sådan kontroll hittills föreslagits endast för paketet "xz". Om experimentet lyckas planerar man att använda kontrollerna även för andra paket i nixpkgs.

Källa: opennet.ru