Om de Nixpkgs-pakketrepository die in de NixOS-distributie wordt gebruikt, te integreren, is een modus voor repetitieve builds voorgesteld, die de mogelijkheid biedt om gevallen van code-injectie met backdoors, vergelijkbaar met het incident met het XZ-project, te identificeren. De voorgestelde beschermingsmethode maakt het mogelijk om wijzigingen in de archieven met de broncode van de release te detecteren die ontbreken in de code-repositories.
De essentie van de methode is dat de broncode van de nieuwe versie van de applicatie twee keer wordt opgebouwd: de eerste keer uit de code die uit de git-repository is gedownload, en de tweede keer uit de code die in kant-en-klare archieven wordt verspreid. Als de resulterende binaire bestanden van de builds verschillen, ontstaat er reden tot vermoeden van verborgen wijzigingen in de repository of in het archiefbestand met de code.
Ter herinnering, in het geval van het XZ-project bevatte de code-repository geen verdachte wijzigingen. De backdoor-componenten werden geleverd binnen bestanden die werden gebruikt in de testset voor de controle van de werking van de XZ-decompressor. De backdoor werd geactiveerd op het niveau van het build-systeem, terwijl de broncode van XZ overeenkwam met de code uit de repository. De activerende backdoor m4-macros voor de Automake-toolkit waren alleen opgenomen in het kant-en-klare archief met de code en ontbraken in de repository.
De backdoor in XZ werd ingevoegd door een aanvaller die de status van maintainer in het project heeft verworven. De invoeging van de backdoor werd onmiddellijk niet opgemerkt omdat distributies in de meeste gevallen pakketten samenstellen door code uit kant-en-klare archieven te downloaden, waarbij een enkele checksum voor de integriteitscontrole van het archiefbestand volstaat en gebruik kan worden gemaakt van mirrors. De belangrijkste focus bij het controleren van de code ligt op de analyse van de inhoud van de repository, dus niet-evidente verschillen in archieven kunnen niet altijd onmiddellijk worden ontdekt.
Om de verificatie van archiefbestanden en repository-slices die overeenkomen met releases te vergemakkelijken, hebben sommige open-sourceprojecten, zoals PostgreSQL, een systeem voor herhaalbare archiefgeneratie geĆÆntroduceerd. In dit geval wordt er een instrumentarium aangeboden waarmee je zelf een archief kunt samenstellen uit de code, volledig overeenkomend met het beschikbare archief voor download. Als het onafhankelijk gemaakte archief verschilt van het archief dat door het moederproject wordt geleverd, is er sprake van compromittering van de repository of het referentiearchief.
Het probleem is dat deze methode slechts in enkele gevallen wordt toegepast, terwijl veel projecten doorgaan met het opnemen van aanvullende artefacten in de archieven, die ontbreken in de hoofdrepository, zoals man-pagina's, documentatie, voorbeelden, pakketbouwscripts voor distributies en extra bouwbestanden. Dit gebeurt voornamelijk om historische redenen en de eigenschappen van het releaseproces. Een eenvoudige controle van de overeenstemming tussen de inhoud van de repository en het archief is in dit geval niet geschikt.
Als oplossing is voorgesteld om de binaire bestanden van de release zowel uit de repository (bijvoorbeeld, het automatisch gegenereerde archief op GitHub voor de reltag) als uit het archief, dat door de maintainer is voorbereid, te verzamelen en vervolgens het resultaat te vergelijken. Als experiment is deze controle voorlopig alleen voorgesteld voor het pakket 'xz'. Als het experiment succesvol blijkt, zijn er plannen om dergelijke controles ook in andere pakketten in nixpkgs te gebruiken.
Bron: opennet.ru
