Per l'inclusione nel repository dei pacchetti nixpkgs, utilizzato nella distribuzione NixOS, è stato proposto un metodo di build ripetibili, in grado di identificare casi di inserimento di backdoor nel codice, simili all'incidente con il progetto XZ. Il metodo di protezione presentato consente di rilevare modifiche negli archivi del codice sorgente delle versioni che non sono presenti nei repository del codice.
L'essenza del metodo consiste nel compilare il codice sorgente di una nuova versione dell'applicazione due volte: la prima volta dal codice scaricato dal repository git, e la seconda dal codice distribuito in archivi pronti. Se i file binari ottenuti dalle compilazioni differiscono, sorgono sospetti di modifiche nascoste nel repository o nel file di archivio contenente il codice.
Ricordiamo che nel caso del progetto XZ, il repository del codice non conteneva modifiche sospette. I componenti malevoli che costituivano la backdoor erano forniti all'interno di file utilizzati nel set di test per verificare il corretto funzionamento del decompressore XZ. La backdoor si attivava a livello di sistema di build, mentre il codice sorgente di XZ corrispondeva al codice del repository. I macro m4 attivatori della backdoor per gli strumenti Automake erano inclusi solo nell'archivio pronto con il codice e non erano presenti nel repository.
La backdoor in XZ è stata inserita da un malintenzionato che è riuscito a ottenere lo status di manutentore nel progetto. L'inserimento della backdoor non è stato subito notato poiché le distribuzioni in genere compilano pacchetti scaricando codice da archivi pronti; infatti, durante il caricamento del codice per la compilazione è sufficiente una singola somma di controllo per verificare l'integrità del file con l'archivio e utilizzare mirror. L'attenzione principale durante il controllo del codice è rivolta all'analisi del contenuto del repository, quindi differenze non evidenti negli archivi non sempre possono essere rilevate immediatamente.
Per semplificare la verifica della corrispondenza tra file di archivio e snapshot del repository relativi alle versioni, alcuni progetti open source, come PostgreSQL, hanno introdotto un sistema per la generazione ripetibile degli archivi. In questo caso, viene fornito un tool che consente di creare autonomamente un archivio dal codice, completamente corrispondente all'archivio pronto per il download. Se l'archivio creato indipendentemente e l'archivio fornito dal progetto principale differiscono, si ha una compromissione del repository o dell'archivio di riferimento.
Il problema è che tale metodo viene applicato solo in casi specifici, mentre molti progetti continuano a includere negli archivi artefatti aggiuntivi che non sono presenti nel repository principale, come pagine man, documentazione, esempi, script per la creazione di pacchetti per le distribuzioni e file sorgente aggiuntivi. Questo avviene principalmente per motivi storici e per le peculiarità dei processi di creazione delle versioni. Una semplice verifica della corrispondenza tra il contenuto del repository e quello dell'archivio non è quindi sufficiente.
Come soluzione, si propone di raccogliere i file binari di rilascio sia dal repository (ad esempio, utilizzando l'archivio generato automaticamente in GitHub per il tag di rilascio), sia dall'archivio preparato dal manutentore, confrontando poi i risultati. Come esperimento, l'inclusione di tale verifica è stata proposta finora solo per il pacchetto "xz". Se l'esperimento avrà successo, si prevede di utilizzare verifiche simili anche negli altri pacchetti in nixpkgs.
Fonte: opennet.ru
