{"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\/news\/v-nixos-predlozhen-metod-zashhity-ot-podstanovki-bekdorov-takih-kak-v-xz","title":{"rendered":"In NixOS \u00e8 stato proposto un metodo di protezione contro la sostituzione di backdoor, come in 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, 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. <\/p>\n
L'essenza del metodo consiste nel fatto che il codice sorgente della nuova versione dell'applicazione viene compilato 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 sono diversi, si ha motivo di sospettare la presenza di modifiche nascoste nel repository o nel file di codice archiviato. <\/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 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. <\/p>\n
La backdoor in XZ \u00e8 stata inserita da un malintenzionato che \u00e8 riuscito a ottenere lo status di manutentore nel progetto. L'inserimento della backdoor non \u00e8 stato subito notato poich\u00e9 le distribuzioni in genere compilano pacchetti scaricando codice da archivi pronti; infatti, durante il caricamento del codice per la compilazione \u00e8 sufficiente una singola somma di controllo per verificare l'integrit\u00e0 del file con l'archivio e utilizzare mirror. L'attenzione principale durante il controllo del codice \u00e8 rivolta all'analisi del contenuto del repository, quindi differenze non evidenti negli archivi non sempre possono essere rilevate immediatamente. <\/p>\n
Per semplificare la verifica della corrispondenza tra i file-archivio e i ritagli 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 un toolkit che consente di compilare autonomamente il proprio archivio dal codice, completamente corrispondente all'archivio pronto disponibile per il download. Se l'archivio creato indipendentemente e l'archivio fornito dal progetto principale differiscono \u2014 si ha una compromissione del repository o dell'archivio di riferimento. <\/p>\n
Il problema \u00e8 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\u00e0 dei processi di creazione delle versioni. Una semplice verifica della corrispondenza tra il contenuto del repository e quello dell'archivio non \u00e8 quindi sufficiente. <\/p>\n
Come soluzione, si propone di compilare i file binari di rilascio sia dal repository (ad esempio, utilizzando l'archivio generato automaticamente in GitHub per il tag di rilascio) che dall'archivio preparato dal manutentore, confrontando poi i risultati. Come esperimento, l'inclusione di tale verifica \u00e8 stata per ora proposta solo per il pacchetto \u00abxz\u00bb. Se l'esperimento avr\u00e0 successo, si prevede di utilizzare le verifiche anche in altri pacchetti in nixpkgs. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"