Az NixOS disztribúciójában alkalmazott nixpkgs csomagokra vonatkozóan javasolták az ismételhető építések üzemmódot, amely lehetővé teszi a hátsó ajtók beépítésének észlelését a kódban, hasonlóan az XZ projekt incidenséhez. A bemutatott védelmi módszer lehetővé teszi a kiadott forráskód-archívumokban található, a kódot tartalmazó tárolókban nem létező módosítások felfedezését.
A módszer lényege, hogy az alkalmazás új verziójának forráskódját kétszer fordítják le — először a git-tárolóból letöltött kód alapján, másodszor pedig a kész archívumokban terjesztett kód alapján. Ha a két építésből származó bináris fájlok eltérnek, gyanú támad a tárolóban vagy a kódarchívumban rejlő rejtett módosítások miatt.
Emlékeztetünk arra, hogy az XZ projekt esetében a kód tárolója nem tartalmazott gyanús módosításokat. A hátsó ajtót képező rosszindulatú összetevők azokban a fájlokban voltak megtalálhatók, amelyeket az XZ kibővített működésének tesztelésére használtak. A hátsó ajtó a gyűjtési szinten aktiválódott, miközben az XZ forráskódja megegyezett a tárolóból származó kóddal. A hátsó ajtót aktiváló m4 makrók az Automake eszközkészlethez csak a végleges kódarchívumban voltak benne, a tárolóban viszont nem.
Az XZ hátsó ajtaját egy támadó helyezte el, aki megszerezte a projektegyesítő státuszt. A hátsó ajtó beillesztése azonnal nem lett észlelve, mivel a disztribúciók általában a kódot kész archívumokból töltik le, mivel a kód letöltéséhez elegendő egy ellenőrző összegezés a fájl integritásának ellenőrzéséhez, és tükrözőkat használhatnak. A kód ellenőrzésére összpontosító figyelem a tároló tartalmának elemzésére összpontosít, így az archívumokban lévő nem nyilvánvaló eltéréseket nem mindig lehet azonnal észlelni.
A fájlarchívumok és a kiadásoknak megfelelő tárolók ellenőrzésének megkönnyítése érdekében néhány nyílt projekt, például a PostgreSQL, bevezették a megismételhető archívum-generálás rendszerét. Ebben az esetben olyan eszközöket biztosítanak, amelyek lehetővé teszik a felhasználók számára, hogy a forráskód alapján saját archívumot állítsanak elő, amely teljes mértékben megfelel a letölthető kész archívumnak. Ha az önállóan létrehozott archívum és a fő projekt által biztosított archívum eltér, az a tároló vagy az referencia-archívum kompromittálódását jelenti.
A probléma az, hogy az ilyen módszer csak bizonyos esetekben alkalmazott, míg sok projekt továbbra is további artefaktumokat, például man-oldalakat, dokumentációt, példákat, csomagolási forgatókönyveket és extra build fájlokat tartalmaz a fő tárolóban való hiányzással. Ezek jellemzően történeti okokból és a kiadási folyamatok sajátosságai miatt történnek. Az archívum és a tároló tartalmának egyszerű ellenőrzése ebben az esetben nem megfelelő.
Megoldásként felmerült, hogy a kiadás bináris fájljait a tárolóból (például a GitHub-on automatikusan generált archívumot lehet használni a kiadási címkéhez), valamint a karbantartó által előkészített archívumból állítsák elő, majd összehasonlítják az eredményt. Kísérletként ilyen ellenőrzéseket egyelőre csak az 'xz' csomag számára javasoltak. Ha a kísérlet sikeres lesz, más csomagokban a nixpkgs is tervezi az ilyen ellenőrzések alkalmazását.
Forrás: opennet.ru
