Come anche gli operatori del settore più distratti si saranno resi conto, la backdoor inserita nel codice del tool XZ di cui abbiamo parlato la scorsa settimana, tolte le evidenti problematiche effettive nell’ambito sicurezza, ha generato una serie di azioni e discussioni che certamente andranno avanti a lungo.

È già comunque possibile osservare alcune conseguenze, cambi di rotta, decisioni prese in modo che i progetti possano essere tutelati da situazioni disastrose come quella accaduta con XZ.

Si può partire da un aspetto relativo all’atteggiamento. Tutti si sono resi conto di come questa CVE (CVE-2024-3094) non sia stata una CVE come le altre. La domanda che molti si pongono è: quante backdoor come quella di XZ ci sono in giro? C’è da scommettere che decine di Rick Deckard siano già al lavoro, ed è evidente come la questione enfatizzi la gravità di quanto accaduto, tanto che qualcuno ipotizza come il danno sia ancora più grave di quanto appaia, vedi Joab Jackson di The New Stack.

Jackson ha indagato sulla figura dell’autore della backdoor, quel Jia Tan che ormai è diventato il nemico pubblico numero uno. Uno pseudonimo forse, il frutto di social engineering, un attacco che qualcuno suggerisce essere the best-executed supply chain attack we’ve seen described in the open. Non si è ancora capito chi sia (o siano), ma si è capito che non si può più prescindere dallo zero trust più totale, se si vuole sopravvivere.

Altro aspetto che è già emerso ed emergerà ancora di più riguarda il proliferare di software scanner per rilevare backdoor di questo tipo. Il panorama IT è già pregno di questo tipo di programmi, ma questa nuova, ed inattesa forma di attacco cambia le carte in tavola.

Sul sito https://xz.fail/ è disponibile un tool creato ad arte per l’identificazione di questo malware. Basta caricare il binario ELF sospetto per avere uno scan live che indichi se l’eseguibile risulti o meno affetto dalla backdoor.

C’è infine un aspetto comune a molti software, ossia le dipendenze. Ogni software ne ha, possono facilitare ed agevolare il funzionamento, ma molte volte sono anche inutili e rischiose. Ecco perché un software – anche se il termine è un tantino riduttivo in questo caso poiché stiamo parlando di un intero sistema di init – legato a XZ, come Systemd, ha deciso di ridurre drasticamente le dipendenze dai tool sshd e xz.

Lo racconta Bobby Borisov nell’articolo dal titolo After a Recent SSH Vulnerability, Systemd Reduces Dependencies, dove viene proposta la riduzione delle dipendenze di libsystemd per includere solo libc, la libreria C standard, riducendo così al minimo la superficie di attacco per potenziali minacce alla sicurezza.

Per intenderci il nuovo approccio sarà: per colpa di qualcuno, non si fa credito a nessuno. Infatti se le attuali implementazioni includono molte altre librerie, queste potrebbero non essere necessarie per implementare le funzionalità principali di libsystemd e verranno quindi rimosse.

È facile capire come questo tipo di approccio verrà presto applicato anche da altri progetti e tanto per Systemd, quanto per tutti gli altri, richiederà parecchio effort, poiché è più facile dire che fare quando si lavora con le dipendenze. È però anche una cosa molto, molto logica.

Ogni giorno il numero articoli di approfondimento sul tema aumenta e come raccontavamo in apertura di questo problema si parlerà ancora a lungo, quindi sicuramente non è finita qui, ma almeno per oggi, è tutto.

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.