{"id":122969,"date":"2025-03-25T10:22:42","date_gmt":"2025-03-25T08:22:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz"},"modified":"2025-03-25T10:22:42","modified_gmt":"2025-03-25T08:22:42","slug":"v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"In NixOS \u00e8 stato proposto un metodo di protezione contro l'inserimento di backdoor, come nel caso di XZ.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Per l'inclusione nel repository dei pacchetti nixpkgs, utilizzato nella distribuzione NixOS, \u00e8 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. <\/p>\n
La sostanza del metodo \u00e8 che il codice sorgente di una nuova versione dell'applicazione viene costruito due volte \u2014 la prima volta dal codice caricato dal repository git, e la seconda dal codice distribuito in archivi pronti. Se i file binari risultanti dalle compilazioni differiscono, sorge il sospetto di modifiche nascoste nel repository o nel file di archivio del codice. <\/p>\n
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. <\/p>\n
La backdoor in XZ \u00e8 stata inserita da un malintenzionato che ha ottenuto lo status di maintainer nel progetto. L'inserimento della backdoor non \u00e8 stato subito notato poich\u00e9 le distribuzioni generalmente compongono i pacchetti caricando il codice da archivi pronti; cos\u00ec facendo, si pu\u00f2 fare affidamento su un'unica somma di controllo per verificare l'integrit\u00e0 del file d'archivio e utilizzare mirror. L'attenzione durante il controllo del codice \u00e8 concentrata sull'analisi del contenuto del repository, pertanto le differenze non evidenti negli archivi non sempre possono essere rilevate immediatamente. <\/p>\n
Per semplificare la verifica della corrispondenza tra i file di archivio e i livelli del repository, corrispondenti alle versioni, alcuni progetti open source, come PostgreSQL, hanno introdotto un sistema di generazione ripetibile degli archivi. In questo caso, viene fornito uno strumento che consente di costruire autonomamente il proprio archivio a partire dal codice, completamente conforme all'archivio pronto disponibile per il download. Se l'archivio creato indipendentemente e l'archivio fornito dal progetto principale differiscono \u2014 si verifica una compromissione del repository o dell'archivio di riferimento. <\/p>\n
Il problema \u00e8 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\u00e0 dei processi di rilascio. Una semplice verifica della corrispondenza tra il contenuto del repository e l'archivio in questo caso non \u00e8 appropriata. <\/p>\n
Come soluzione si propone di costruire i file binari della release sia dal repository (ad esempio, \u00e8 possibile utilizzare l'archivio generato automaticamente in GitHub per il tag di rilascio), sia dall'archivio preparato dal maintainer, confrontando poi il risultato. Come esperimento, l'inclusione di un simile controllo \u00e8 attualmente proposta solo per il pacchetto \u00abxz\u00bb. Se l'esperimento avr\u00e0 successo, si prevede di utilizzare tali verifiche anche in altri pacchetti in nixpkgs. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"