Durante le ultime vacanze di Pasqua si è scatenato un vero e proprio tsunami nel mondo Linux a causa di una backdoor che in qualche modo (ci arriviamo fra poco) è stata inserita all’interno dei sorgenti delle XZ Utils. La vulnerabilità di cui stiamo parlando ha già un nome ed un cognome: CVE-2024-3094 (categoria 10.0 ossia CRITICAL, la peggiore possibile) e riguarda le versioni 5.6.0 e 5.6.1 di XZ Utils.
Lo scorso venerdì, manco a dirlo di passione, Red Hat ha pubblicato in un blog alcuni dettagli che pian piano hanno delineato la portata del problema:
Yesterday, Red Hat Information Risk and Security and Red Hat Product Security learned that the latest versions of the “xz” tools and libraries contain malicious code that appears to be intended to allow unauthorized access. Specifically, this code is present in versions 5.6.0 and 5.6.1 of the libraries. […]
PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES for work or personal activity.
Ieri Red Hat Information Risk and Security e Red Hat Product Security hanno realizzato come le versioni di tool e librerie “xz” contengono codice malevolo ideato per consentire accessi non autorizzati. Specificamente questo codice è presente nelle versioni 5.6.0 e 5.6.1 delle librerie. […]
PER FAVORE EVITATE DI USARE QUALSIASI ISTANZA DI FEDORA RAWHIDE per lavoro o attività personali.
Fedora “Rawhide” è il nome in codice per la versione di sviluppo di Fedora che include le ultime modifiche, funzionalità e aggiornamenti software prima che siano stati completamente testati e rilasciati nelle versioni stabili e per quanto possa sembrare “normale” trovare vulnerabilità in una versione di sviluppo questa situazione non lo è per nulla. Primo perché Fedora Rawhide al momento è lo sviluppo di Fedora 40, di prossima uscita, e quindi verosimilmente usata da moltissimi utenti, secondo perché il problema è di una gravità estrema, basti osservare la sua catalogazione.
Il problema è talmente grave che anche Debian ha sospeso la creazione di nuove release (vedi https://micronews.debian.org/2024/1711830544.html) e di posporre l’uscita della versione 12.06 (vedi https://linuxiac.com/debian-decided-to-postpone-the-12-6-release/) e GitHub ha disabilitato il repository upstream di XZ (vedi https://github.com/tukaani-project/xz).
L’analisi condotta da Andres Freund, ingegnere Microsoft, e pubblicata su Openwall è impietosa: chi ha infettato il repository ha inserito uno script offuscato che attiva questa backdoor. Questo script quando non riesce ad attivarsi rallenta in maniera sensibile i login SSH, ed è proprio così che Freund se n’è accorto. Quindi non fosse stato per l’esigenza di capire cosa stesse rallentando le connessioni SSH probabilmente questa backdoor avrebbe invaso ancora di più le installazioni ed i pacchetti delle varie distribuzioni che consideriamo stabili, non solo quelle evidenziate sinora, di classe “devel”.
Insomma, un grave, gravissimo pasticcio che è al momento in gestione (delizia dell’open-source), ma la cui causa parte da lontano (croce dell’open-source), molto lontano, nel 2022 precisamente, sulla mailing list xz-devel:
I haven’t lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I’ve worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we’ll see. It’s also good to keep in mind that this is an unpaid hobby project.
Non ho perso interesse, ma il tempo da dedicare al progetto è stato abbastanza limitato principalmente a causa di problemi di salute mentale a lungo termine, ed altre cose. Recentemente ho lavorato un po’ fuori lista con Jia Tan su XZ Utils e forse avrà un ruolo più importante in futuro, vedremo. È anche bene tenere presente che si tratta di un progetto hobby non retribuito.
Quindi quanto successo è molto chiaro: il maintainer del progetto, Lasse Collin, è andato in burnout e questo ruolo è risultato per così dire vacante, lasciando il software non aggiornato e facile preda dei malintenzionati che lo hanno infettato con una backdoor che, lo ricordiamo, è stata scoperta per puro caso.
Ed al danno si aggiunge la beffa, perché anche se non ci sono ancora conferme certe pare che la modifica della backdoor sia proprio stata fatta da Jia Tan, il maintainer succeduto a Collin nella gestione del progetto, che era ritenuta persona affidabile.
Da qualsiasi angolazione la si guardi questa notizia appare davvero orribile.
Chissà se insegnerà qualcosa in merito ai rischi che il corso attuale dell’open-source sta prendendo. Quando si parla di burnout, quando si discute di come dovrebbe essere migliorato il modello attuale, quando si riflette in generale su quanto diamo per scontato cose che in realtà non lo sono, il rischio è sempre quello di essere presi a schiaffi dalla realtà delle cose.
E questo di XZ è uno schiaffo bello forte.
Possibile che ci si debba sempre ridurre a guardare questa vignetta di Xkcd:
A volte con un sorriso, a volte scuotendo la testa?
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.
È proprio quello che mi sono chiesto anche io: e se ci fossero altre backdoor inserite nei più noti software che usiamo nel mondo open source? Beh, basta essere paranoici e cerchiamo di vivere tranquilli.
Mi chiedo: “e adesso?”
Cosa bisogna fare perché l’errore non si ripeta? I distributori si impegneranno nel controllare il codice prima di pacchettizzarlo magari?
Risorse che per forza di cose verranno sottratte a qualcos’altro. Magari se c’è da rallentare un po sulle novità e concentrarsi su bugfix e controllo sicurezza non guasterebbe?
Penso che il problema sia differente. XZ non era aggiornato dal 2022, quindi non era certamente un software “edge”, quanto piuttosto un software abbandonato.
Anche volendo un controllo postumo come quello che auspichi è impossibile, sono i team dei progetti che dovrebbero avere dei processi di review tali per cui problemi come questo vengano eliminati a monte, ma in questo caso “team” == “una singola persona”, da qui tutti i problemi.
E come dice @sbaragnaus:disqus il problema è che di software così ce ne sono a bizzeffe, quindi mi vien da dire: cara grazia che se ne sono accorti…
Capito. Quindi chi pacchettizza non controlla quasi mai ciò che pacchettizza?
Immagino (spero) che dopo questo spauracchio un po di sana paranoia possa nascere.
Capito
Mica solo open source
Sì sì, il dubbio c’è, ma il mondo open source, vista la maggiore trasparenza, è quello dove meno ci si aspettano problemi di genere.
Sempre detto che la maggior parte dei problemi Windows su Linux non li abbiamo solo perché non conta numericamente… E ora abbiamo aperto il vaso di Pandora e indovinate un po’… La scoperta dell’acqua calda proprio…
Passiamo a BSD 😀 o al massimo a RHEL desktop
Non è assolutamente vero che non conta numericamente. A livello desktop è innegabile, ma a livello server di fatto internet è basata su Linux. Non è un vaso di Pandora, ma l’evidenza che il modello attuale sta evidenziando tutti i suoi limiti.
Pensi che si possa ovviare a questi limiti in modo concreto e attuabile fin da subito o comunque nel più breve tempo possibile?
Perché altrimenti questi ristudiano i punti deboli e sfondano ancora una volta…
La cosa più preoccupante è che, a quanto pare, ad aver inserito la backdoor è stato proprio il suo (unico) maintainer, quel Jia Tan riportato nell’articolo. Il che stravolge tutto il paradigma della supply chain: in questo caso chi controllava il controllore era il controllore. Un disastro.
Sisi capisco, terrificante.
Vedo veramente difficile un controllo a monte di tutti i pacchetti più usati, a meno i grandi dell’open source (Red Hat, ecc.) non decidano di dedicare risorse economiche a questo scopo.
Ps. Magari questo incidente ci aiuta a capire meglio quanto sia davvero fondamentale il lavoro di fare le pulci ai commit del kernel da parte di Linus Torvalds, anche se questo talvolta risulta antipatico.
Si, paga i dev… Azz non si può fare…
Appunto, è esattamente quello che ho detto, ora che stai prendendo più “margine nel mondo” diventi target, piano piano… Ad oggi l’utenza desktop Linux non è target e sostanzialmente il target sono applicazioni di backend e core ma più che altro per penetrare i server, ma anche li spesso il dato gira su un altro applicativo e così via…
Parliamoci chiaro gli interessa prendere i dati non obbligatoriamente il controllo… Questo di xz è sembrato più un gesto di stizza che un vero e proprio attacco ben congeniato.
E’ esattamente il contrario. Non c’è niente di stizza. E’ stato tutto pianificato. Questo tizio Jan, ha lavorato per mesi, per prendere volutamente il controllo del progetto ed innestare la backdoor. Questo sapeva bene, che la libreria di xz, veniva usata in systemd e per la modalità con cui openssh notifica a systemd. Se gli fosse andata bene gli avrebbe consentito di avere il controllo su ogni sistema linux con systemd a bordo, senza però toccare nulla ne su systemd ne su openssh che avrebbe destato maggiori sospetti.
Gli sarebbe bastato non rallentare ssh, ora chiamala stupidità per me è semplicemente legato al fatto che non fosse una cosa architettata a tavolino ma più un gesto di stizza per dire “vedete”.
“gli sarebbe bastato non rallentare SSH” come se fosse stato voluto. E parliamo di 4-500ms.
La backdoor era ovviamente complicatissima, offuscata, ed è stata scoperta per alcuni errori della 5.6.0 (solo in alcuni casi) che sarebbero stati fixati nella 5.6.1. Siamo stati fortunati, un piccolo errore, ed un dev molto scrupoloso.
Beh un buon programma può attivarsi in parallelo senza rallentarne un altro, lui da quel che ho capito si è messo in cascata rallentando il processo… Voluto o non voluto rimane comunque una scelta non da “professionisti” ne convieni?
non conta numericamente ??? è installato su ogni aggeggio che si collega a internet e non, dai televisori alle lavatrici (sulle tv poi, quelle attuali, non credo non ce ne sia nessuna in commercio che non abbia un kernel linux) per non parlare dei dispositivi squisitamente votati come i router più o meno casalinghi e molti frà i dispositivi tipo switch etc. E senza voler tirare in ballo tutti i telefoni android. Se la mettiamo in termini numerici, linux surclassa windows di diversi ordini di grandezza… che poi sui desktop pc, sia inesistente, e quindi invisibile ai più, questo è sen’altro vero.
Finito l’inutile lezioncina? Difficile leggere tra le righe che mi riferissi al panorama desktop dove infatti si sente la solita affermazione “Linux è più sicuro di Windows”?
Ed è vero
Tecnicamente se prendo il kernel così come lo trovi nel 90% delle distribuzioni è un colabrodo peggio di Windows… Cioè hardening non è difficile farlo ma non ti viene a gratis…
quando uno scrive “…su Linux non li abbiamo solo perché non conta numericamente…” e’ chiaro che la lezioncina vada ripetuta.
È la realtà, se avessi sul desktop uno share maggiore saresti target, Android infatti è target, le varie smarttv non hanno ancora share interessanti, per gli altri dispositivi ci sono varie falle, il fatto che non le chiudano non significa che siano al sicuro…
Pensate se il successore di Torvalds possa essere un Jia tan…
Il problema non riguarda progetti come il Kernel Linux o Kubernetes con community immense, bensì i “pesci piccoli” che però hanno un ruolo cruciale (vedi immagine Xkcd)…
Come si può cambiare l’ecosistema opensource senza snaturalizzarlo?
Di sicuro, per come la vedo io, non con i fork. La via di Perens è una proposta sensata, ma la cosa che a me sconvolge e infastidisce è che chi si è posto a tutela di quell’aspetto (la Linux Foundation) in realtà fa il gioco delle grandi corporation che la sovvenzionano.
Si, un disastro, forse le distribuzioni non dovrebbero utilizzare come software “essenziale” piccoli progetti o nel caso avere due occhi ben aperti su di essi.
o forse sarebbe il caso che condividessero qualche profitto e qualche sviluppatore, magari anche a tempo parziale, con i poveri cristi che lavorano da soli in questi progetti minori, ma che loro prendono a piene mani.
In realtà la cosa sia sembra piú complessa. Sembra che il Jia Tan abbia lavorato di social engeneering per diventare, di proposito, manutentore del progetto, facendo pressioni sul vecchio manteiner attraverso messaggi ed email fasulli. Anche la modalità con cui lavora il tutto, sfruttando la modalitá con cui openssh comunica con systemd (sempre lui di mezzo anche questa volta… e poi dicono che sono un dinosauro) denota un grado di sofisticazione, che induce a pensare sia stata un operazione orchestrata da un gruppo ben organizzato, forse uno stato.
Mi chiedo a questo punto, quanti altre situazioni siano passate senza che ce ne siamo resi conto.
Mi sa che il tempo delle mele sia finito e occora una catena di controllo piú serrata anche sui tools.considerati minori.
Maggiori info le ho trovate anche qua:
https://www.insicurezzadigitale.com/backdoor-su-xz-il-problema-e-molto-piu-grande-non-e-lopen-source-e-non-si-risolve-con-un-aggiornamento-una-storia-incredibile/
Secondo me se ne esce, mettendo alla “gogna” chi produce o mantiene quel software e lo si bandisca dal mondo Linux, così ci penserebbero 2 volte prima di fare cazzate, perché verrebbero sputtanati….
E se un maintainer si costruisse una falsa identità?
Cambiando un po’ il discorso…. Le VPN ti proteggono, ma chi ti protegge dalle VPN? …. Paranoia? …. forse , ma quando qualcuno ha tanto potere, poi finisce che lo usa a proprio vantaggio….!
Questo grave attacco dovrebbe portare al centro dell’attenzione i gravi problemi che affliggono il modello di sviluppo e manutenzione del software open source.
In secondo luogo, a meno che non si abbiano esigenze davvero particolari, per gli utenti normali è decisamente preferibile scegliere distro il cui modello di rilascio delle versioni è basato sulla stabilità e non sul rolling release. In breve: imho meglio Ubuntu/Debian rispetto a Fedora o Arch (d’altra parte Arch è esplicitamente rivolta ad utenti esperti)
sinceramente quello che non capisco è il motivo per cui le distribuzioni “importanti” decidano di utilizzare software “personali” e non gestiti da foundation o comunque gruppi organizzati seriamente.
fosse per me una distro come debian o fedora non dovrebbe proprio contenere pacchetti “one-man-show”
Considera che ci sono letteralmente un mare di utility e programmi Unix/Linux nello stesso stato di xz. Il problema è darli per “scontati”.
Il problema è che la Linux Foundation si preoccupa di sovvenzionare fork di software come Redis anziché preservare un sano ecosistema di software come xz che ne ha un estremo bisogno.
La speranza è che questa vicenda di xz serve a svegliare un po’ di coscienza, ma dubito sarà così.
infatti, per me una distro “seria” dovrebbe pacchettizzare (o almeno istallare di default) solo roba supervisionata da team validi. (gnu, linux foundation, apache, etc etc)
la roba one man show dovrebbe proprio essere bandita.
ti serve XZ? lo paghi per entrare in uno dei team o fai un fork gestito….
quando penso che curl è utilizzato ma miliardi di persone è gesitito da tipo 1 sola persona…
fossi io dopo 30 anni che nessuno mi paga ci metterei un cripto miner dentro nella migliore delle ipotesi
No però aspetta. La gestione di curl è paritetica a quella del Kernel eh… Stenberg nella gestione è paritetico a Torvalds, così come sono identici a livello di serietà, tant’è che guarda caso sono entrambi CNA. Quindi no, curl è proprio l’esempio sbagliato.
A menomale, avevo capito che Stenberg fosse da solo
Sono davvero felice che questo tema sia stato trattato così bene!
Ho letto un articolo sul Times che ha solo elogiato Freund per aver trovato il problema, e da nessuna parte hanno detto che Collin: era in burnout, ha dovuto lasciare le redini a Jia, e inoltre che l’account GitHub di Collin sia stato ingiustamente bloccato!