La backdoor nei sorgenti di XZ che ha provocato un vero e proprio tsunami nel mondo Linux arriva da lontano ed ha un colpevole: il burnout

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.

43 risposte a “La backdoor nei sorgenti di XZ che ha provocato un vero e proprio tsunami nel mondo Linux arriva da lontano ed ha un colpevole: il burnout”

  1. Avatar Capitano Nemo
    Capitano Nemo

    Passiamo a BSD 😀 o al massimo a RHEL desktop

  2. Avatar sbaragnaus
    sbaragnaus

    È 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.

  3. Avatar Black_Codec

    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…

  4. Avatar Capitano Nemo
    Capitano Nemo

    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?

  5. Avatar Giacomo Perin
    Giacomo Perin

    Pensate se il successore di Torvalds possa essere un Jia tan…

  6. Avatar Raoul Scarazzini

    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…

  7. Avatar Raoul Scarazzini

    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)…

  8. Avatar Capitano Nemo
    Capitano Nemo

    Capito. Quindi chi pacchettizza non controlla quasi mai ciò che pacchettizza?
    Immagino (spero) che dopo questo spauracchio un po di sana paranoia possa nascere.

  9. Avatar Raoul Scarazzini

    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.

  10. Avatar Capitano Nemo
    Capitano Nemo

    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…

  11. Avatar Capitano Nemo
    Capitano Nemo

    Capito

  12. Avatar Raoul Scarazzini

    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.

  13. Avatar Capitano Nemo
    Capitano Nemo

    Sisi capisco, terrificante.

  14. Avatar Giacomo Perin
    Giacomo Perin

    Come si può cambiare l’ecosistema opensource senza snaturalizzarlo?

  15. Avatar Raoul Scarazzini

    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.

  16. Avatar sbaragnaus
    sbaragnaus

    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.

  17. Avatar JustATiredMan
    JustATiredMan

    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/

  18. Avatar JustATiredMan
    JustATiredMan

    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.

  19. Avatar carlo coppa
    carlo coppa

    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.

  20. Avatar Soleluna
    Soleluna

    Mica solo open source

  21. Avatar JustATiredMan
    JustATiredMan

    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.

  22. Avatar Black_Codec

    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.

  23. Avatar Black_Codec

    Si, paga i dev… Azz non si può fare…

  24. Avatar Black_Codec

    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”?

  25. Avatar Soleluna
    Soleluna

    Ed è vero

  26. Avatar JustATiredMan
    JustATiredMan

    quando uno scrive “…su Linux non li abbiamo solo perché non conta numericamente…” e’ chiaro che la lezioncina vada ripetuta.

  27. Avatar Black_Codec

    È 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…

  28. Avatar Black_Codec

    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…

  29. Avatar JustATiredMan
    JustATiredMan

    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.

  30. Avatar freestyle72
    freestyle72

    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….

  31. Avatar freestyle72
    freestyle72

    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….!

  32. Avatar Enrico Candino

    “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.

  33. Avatar sbaragnaus
    sbaragnaus

    Sì sì, il dubbio c’è, ma il mondo open source, vista la maggiore trasparenza, è quello dove meno ci si aspettano problemi di genere.

  34. Avatar Black_Codec

    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”.

  35. Avatar Black_Codec

    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?

  36. Avatar eueuropean
    eueuropean

    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)

  37. Avatar sbaragnaus
    sbaragnaus

    E se un maintainer si costruisse una falsa identità?

  38. Avatar Alessandro Scarozza
    Alessandro Scarozza

    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”

  39. Avatar jfv
    jfv

    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!

  40. Avatar Raoul Scarazzini

    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ì.

  41. Avatar Alessandro Scarozza
    Alessandro Scarozza

    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

  42. Avatar Raoul Scarazzini

    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.

  43. Avatar Alessandro Scarozza
    Alessandro Scarozza

    A menomale, avevo capito che Stenberg fosse da solo

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *