Venerdì 29 marzo Andres Freund ha pubblicato sulla mailing list oss-security una scoperta che ha scosso il mondo Linux. Il pacchetto xz Utils, che fornisce la libreria di compressione liblzma presente in quasi ogni distribuzione, conteneva una backdoor. La falla è registrata come CVE-2024-3094, con gravità 10 su 10.
Freund stava facendo test di prestazioni su un sistema Debian di sviluppo e ha notato che gli accessi SSH consumavano troppa CPU e impiegavano circa mezzo secondo in più del solito. Mezzo secondo. Seguendo quell’indizio e alcuni errori segnalati da Valgrind, è arrivato a liblzma.
Il codice malevolo non si trova nel repository Git del progetto, ma solo negli archivi di rilascio delle versioni 5.6.0, del 24 febbraio, e 5.6.1, del 9 marzo. Durante la compilazione uno script modificato estrae un oggetto nascosto in alcuni file di test e lo inserisce nella libreria. Su molte distribuzioni il demone SSH carica liblzma attraverso systemd; la backdoor intercetta una funzione usata nell’autenticazione e, secondo le analisi ancora in corso, permetterebbe a chi possiede una chiave privata specifica di eseguire comandi sul server.
Le versioni compromesse erano arrivate quasi solo nelle distribuzioni di sviluppo o a rilascio continuo: Fedora Rawhide e Fedora 40 beta, Debian testing e unstable, Kali, openSUSE Tumbleweed, Arch Linux. Le versioni stabili di Debian, Ubuntu e Red Hat Enterprise Linux non risultano coinvolte. Qualche settimana in più, e la backdoor sarebbe finita nelle release stabili di mezzo mondo.
Due anni di pazienza
Le modifiche portano la firma di Jia Tan, un contributore che dal 2022 si era guadagnato la fiducia del manutentore storico, un volontario sovraccarico, fino a diventare co-manutentore. Intorno a lui altri account, comparsi dal nulla, facevano pressione perché gli venissero dati più poteri. Chi ci sia dietro quel nome non si sa.
Controlla la versione con xz --version. Se è 5.6.0 o 5.6.1, aggiorna subito tramite la tua distribuzione, che sta tornando a versioni sicure. Un sistema esposto in SSH su Internet con una versione compromessa va considerato a rischio: valuta la reinstallazione e il cambio delle chiavi. Verifica anche immagini container e ambienti CI basati su distribuzioni a rilascio continuo.
In produzione, resta sulle distribuzioni stabili. E chiediti da quanti progetti mantenuti da una sola persona dipende la tua infrastruttura.
