Backdoor XZ-Utils: ancora presente in 35 immagini Docker, ecco rischi e mitigazioni

Era fine marzo 2024 quando tutti vennero a conoscenza dell’incidente XZ-Utils (CVE-2024-3094): si scoprì che uno strumento di compressione ampiamente usato nei sistemi Linux come XZ-Utils conteneva una backdoor deliberatamente inserita. In tanti si riferirono all’incidente come a un “problema minore” perché le versioni 5.6.0 e 5.6.1, che contenevano uno “sgradito ospite”, non sono mai arrivate nei branch stabili delle principali distribuzioni Linux, quindi non hanno toccato, ad esempio, Debian, Ubuntu, RHEL o altre release già consolidate.

Sono comunque finite nelle versioni unstable e testing di Debian, nelle versioni in fase di sviluppo di Fedora e openSUSE, in alcune build nightly o rolling.

Il pacchetto ZX-Utils per Linux conteneva una backdoor

In tanti contestarono anche l’uso del termine backdoor. Eppure, nei pacchetti di XZ-Utils era presente codice che soddisfaceva pienamente la definizione tecnica di backdoor: un componente di codice inserito deliberatamente per consentire accesso o controllo non autorizzato di un sistema, bypassando i meccanismi di sicurezza standard.

Il codice malevolo, introdotto dal contributore “Jia Tan” dopo anni di attività legittima nel progetto, alterava la libreria liblzma.so per intercettare funzioni critiche di OpenSSH, consentendo a chi possedeva una chiave privata speciale di ottenere accesso root remoto senza autenticazione.

Al di là delle colpevoli sottovalutazioni iniziali, l’episodio si è poi rivelato una delle più gravi compromissioni della supply chain open source degli ultimi anni, con diffusione di codice dannoso in pacchetti ufficiali di distribuzioni e container.

L’anatomia del problema

Andres Freund, che a marzo 2024 ha scoperto il problema di sicurezza in XZ-Utils, ha spiegato che il codice malevolo inserito in liblzma.so sfruttava un meccanismo avanzato di hooking per intercettare la funzione RSA_public_decrypt di OpenSSH.

In condizioni specifiche — ossia quando un attaccante si connetteva via SSH utilizzando una chiave privata speciale — la backdoor permetteva il bypassing dell’autenticazione, garantendo accesso root remoto. Il codice era stato inserito da un collaboratore di lungo corso del progetto, noto come “Jia Tan”.

Backdoor XZ-Utils ancora presente in almeno 35 immagini Docker pubbliche

A distanza di mesi dalla scoperta della backdoor XZ-Utils, un’analisi condotta da Binarly ha rivelato che il codice malevolo è ancora presente in almeno 35 immagini Linux su Docker Hub, il più grande registry pubblico di container al mondo. Questa persistenza rappresenta una minaccia concreta per sviluppatori, organizzazioni e pipeline CI/CD che fanno affidamento su immagini precompilate come base per le proprie applicazioni. Con buona pace di chi riteneva, appunto, l’incidente XZ-Utils un “problema minore”.

Come funziona Docker Hub nella filiera software

Docker Hub è il repository ufficiale dove sviluppatori, vendor e community possono pubblicare e scaricare immagini containerizzate. Le immagini sono spesso usate come base per ulteriori personalizzazioni, sia in ambienti di sviluppo che di produzione.

La pratica di utilizzare immagini “di fiducia” direttamente da Docker Hub comporta un rischio critico: se l’immagine di base è compromessa, tutte le immagini che ne derivano ereditano la vulnerabilità o il codice malevolo. Nel caso della backdoor XZ-Utils, il problema si propaga a ogni immagine costruita su quelle infette.

Il nodo critico: immagini compromesse ancora online

Binarly ha individuato almeno 35 immagini Docker pubbliche che contengono la libreria vulnerabile. Molte di esse sono immagini base Debian mai rimosse, nonostante contengano la backdoor.

Sorprendentemente, Debian ha scelto di non rimuovere le immagini infette, dichiarando che:

• Il rischio di sfruttamento è basso, poiché servirebbe un container con sshd installato e attivo;
• l’attaccante dovrebbe avere accesso di rete diretto al servizio SSH;
• sarebbe necessaria la chiave privata trigger specifica della backdoor;
• la rimozione andrebbe contro la continuità dell’archiviazione storica delle immagini.

Una posizione fortemente contestata da Binarly, che evidenzia come il problema non sia solo il rischio diretto, ma anche la possibilità che immagini obsolete siano inavvertitamente utilizzate in build automatizzate, perpetuando la vulnerabilità.

Come mitigare il rischio

Per proteggersi, è fondamentale verificare la versione di XZ-Utils nelle immagini in uso: il pacchetto deve essere aggiornato almeno alla release 5.6.2 (stabile attuale: 5.8.1).

È inoltre consigliabile utilizzare scanner di sicurezza come quelli rilasciati da Binarly e Kaspersky per rilevare la presenza della libreria malevola. Va evitato l’uso di immagini non aggiornate o prive di un ciclo di manutenzione attivo. Ancora, è essenziale utilizzare sempre immagini verificate e integrare controlli di sicurezza per bloccare dipendenze o layer vulnerabili.