Per l'inclusione nel repository dei pacchetti nixpkgs, utilizzato nella distribuzione NixOS, è stato proposto un metodo di build ripetibili che consente di rilevare possibili backdoor nel codice, simili all'incidente con il progetto XZ. Il metodo di protezione presentato permette di identificare modifiche negli archivi di codice sorgente di rilascio non presenti nei repository del codice.
L'essenza del metodo consiste nel compilare il codice sorgente della 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 risultanti differiscono, sorge il sospetto di possibili modifiche nascoste nel repository o nell'archivio del codice.
Ricordiamo che nel caso del progetto XZ, il repository del codice non conteneva modifiche sospette. I componenti malevoli che costituivano la backdoor erano inclusi nei file utilizzati nel set di test per verificare il corretto funzionamento dell'estrattore XZ. La backdoor si attivava a livello di sistema di build, mentre il codice sorgente di XZ coincideva con quello del repository. I macro m4 che attivavano la backdoor per gli strumenti Automake erano inclusi solo nell'archivio di codice pronto e mancavano nel repository.
La backdoor in XZ è stata inserita da un malintenzionato che ha ottenuto lo status di maintainer nel progetto. L'inserimento della backdoor non è stato subito notato poiché le distribuzioni generalmente compongono i pacchetti caricando il codice da archivi pronti; così facendo, si può fare affidamento su un'unica somma di controllo per verificare l'integrità del file d'archivio e utilizzare mirror. L'attenzione durante il controllo del codice è concentrata sull'analisi del contenuto del repository, pertanto le differenze non evidenti negli archivi non sempre possono essere rilevate immediatamente.
Per semplificare la verifica della corrispondenza tra i file di archivio e i tag del repository relativi ai rilasci, alcuni progetti open source, come PostgreSQL, hanno introdotto un sistema di generazione ripetibile degli archivi. In tal caso, viene fornito un set di strumenti che consente di comporre autonomamente il proprio archivio corrispondente all'archivio pronto disponibile per il download. Se l'archivio creato in modo indipendente e l'archivio fornito dal progetto principale differiscono, si è in presenza di una compromissione del repository o dell'archivio di riferimento.
Il problema è che un metodo simile viene praticato solo in casi limitati, mentre molti progetti continuano a includere archivi di artefatti aggiuntivi, assenti nel repository principale, come le pagine man, la documentazione, esempi, script per la creazione di pacchetti per distribuzioni e file di build aggiuntivi. Questo accade principalmente per motivi storici e peculiarità dei processi di rilascio. Una semplice verifica della corrispondenza tra il contenuto del repository e l'archivio in questo caso non è appropriata.
Come soluzione, è stato proposto di generare file binari di rilascio sia dal repository (ad esempio, utilizzando un archivio generato automaticamente in GitHub per il tag di rilascio), sia dall'archivio preparato dal maintainer, confrontando poi i risultati. Come esperimento, l'inclusione di tale verifica è stata finora proposta solo per il pacchetto 'xz'. Se l'esperimento avrà successo, si prevede di utilizzare tali verifiche anche in altri pacchetti in nixpkgs.
Fonte: opennet.ru
