April 2024 - nexa - server-nexa.polito.it

Guida autonoma

by Diego Giorio

April 13, 2024

[CDT:L-1] (supply chain attack) Anatomia di una "backdoor injection" (parte 2)

by 380°

Buongiorno, Executive summary: l'intera questione si può riassumere in una mancanza di verificabilità _pragmatica_ di /alcuni/ file necessari durante le /varie/ fasi di compilazione (build phase), solitamente distribuiti dagli autori del software (upstream) attraverso le cosidette "release tarball" e solitamente usati dagli utilizzatori (downstream) per compilare il binario ed eventualmente distribuirlo. Dopo l'introduzione, è il momento di addentrarci un pochino nelle questioni tecniche (_sistemistiche_) necessarie per una analisi efficace della situazione e di conseguenza ipotizzare una soluzione per _azzerare_ questa classe di attacchi: non sto esagerando, azzerare. Cercherò di essere sintetico al massimo ma certe cose non si possono semplificare senza complicarne irrimediabilmente la comprensione. Innanzi tutto, la pagina ufficiale di Lasse Collin in merito alla backdoor è questa: https://tukaani.org/xz-backdoor/ (1) ...ma non è necessario attendere che lui abbia tempo di scrivere l'articolo che ha in programma, sappiamo già abbastanza. Affinché quell'attacco funzionasse, sono state _indispensabili_ due condizioni: 1. sia il codice di injection (il trojan) che il codice della backdoor stessa (il cosiddetto payload) erano _molto_ nascosti: il trojan in tre (quattro?) script concatenati e offuscati (Stage 0..3), il payload in due files inseriti dagli attaccanti con lo scopo dichiarato di servire per i test del software, che normalmente fanno parte delle fasi di build. Questo è ben spiegato in «xz/liblzma: Bash-stage Obfuscation Explained» [2] --8<---------------cut here---------------start------------->8--- the bash part is split into three (four?) stages of interest, which I have named Stage 0 (that's the start code added in m4/build-to-host.m4) to Stage 2. I'll touch on the potential "Stage 3" as well, though I don't think it has fully materialized yet. Please also note that the obfuscated/encrypted stages and later binary backdoor are hidden in two test files: tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma. --8<---------------cut here---------------end--------------->8--- 2. il primo stadio (Stage 0) trojan era presente _solo_ dentro la release tarball rilasciata upstream, quello pubblicato nel repository git ufficiale (sempre upstream) era diverso. Questo è ben spiegato nelle "FAQ by Sam James" [3] citato in (1): --8<---------------cut here---------------start------------->8--- * The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on GitHub. [...] TODO for this doc [...] * Explain dist tarballs, why we use them, what they do, link to autotools docs, etc * "Explaining the history of it would be very helpful I think. It also explains how a single person was able to insert code in an open source project that no one was able to peer review. It is pragmatically impossible, even if technically possible once you know the problem is there, to peer review a tarball prepared in this manner." --8<---------------cut here---------------end--------------->8--- Perché nessuno si è accorto che build-to-host.m4 presente nella "release tarball" differiva da quello in git? Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools e autoconf e quei file non sono umanamente leggibili, sono sostanzialmente analoghi a quello che in gergo tecnico si chiamano /binary seeds/ [4], anche se scritti in linguaggio shell (credo bash). Al contrario, I file (sorgenti) usati da autotools e autoconf per autogenerare build-to-host.m4 e compagni sono decisamente più umani, si prestano quindi a poter essere verificati e sono ovviamente presenti sia nel VCS ufficiale che nelle "release tarball" ufficiali. La soluzione a questo /primo/ problema è facilissima, quindi: i "downstream consumer" devono semplicemente smetterla di essere _pigri_, perché «this is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf». Quindi i "downstream consumers" semplicemente devono ricordarsi come si usano autotools e autoconf e _usarli_ nelle loro fasi di build, senza scorciatoie. Rimane però il _vero_ problema: controllare che davvero la release tarball contenga esattamente lo stesso codice distribuito nel VCS e NON quello con _aggiunta_ una backdoor (che sia ben nascosta o no non fa differenza) è un lavoraccio e _pragmaticamente_ non lo possono fare le persone; andrebbe automatizzato ma non è possibile, perché le release tarball non sono riproducibili. [5] L'idea che sta raccogliendo più consensi nel progetto Guix - la distribuzione, quindi downstream - et al è quella che le release tarball siano /inemendabili/ dal punto di vista della riproducibilità [6], quindi stanno valutando come effettuare la transizione dai sorgenti presi dalle release tarball a quelli presi direttamente dal VCS, come già avviene per molti pacchetti i cui sorgenti sono disponibili via git. Usando direttamente il codice preso dal VCS upstream si azzererebbero le possibilità di riuscire a nascondere un trojan (tipo build-to-host.m4) in grado di sovvertire il processo di build e fargli installare la backdoor a sua volta nascosta in file binari camuffati da file necessari per i test. Fine della seconda parte. Sto valutando una terza parte per illustrare cosa _non_ risolve questi problemi, ma non vorrei annoiare perché non sono sicurissimo sia on topic in questa lista e... ho la sindrome dell'impostore. Loving, 380° [1] credo che più del 90% di "upstream" usi qualche VCS (es. git, SVN, ecc.) per gestire il proprio codice. [2] https://gynvael.coldwind.pl/?lang=en&id=782 [3] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 [4] http://joyofsource.com/reduced-binary-seed-bootstrap.html [5] la riproducibilità del software è una caratteristica tecnica molto importante sulla quale qui mi tocca soprassedere per non ammazzare di noia chi legge, che se interessato saprà dove cercare [6] per approfondimenti sul perché e il percome si veda ad esempio questo thread nella mailing list guix-devel: https://yhetil.org/guix/8734s1mn5p.fsf@xelera.eu/ -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

April 13, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) Backdoor su Xz: il problema è molto più grande... (parte 1)

by Giacomo Tesio

Salve 380, come Antonio, ho seguito la questione nel suo svilupparsi, con un misto di tristezza e divertimento, tanto da aver preceduto Schneier [1]. Si tratta però di ovvietà: centinaia di simili backdoor sono correntemente in produzione. Forse migliaia. Solo i professionisti del InfoSec possono fingere di credere il contrario (da cui il dramma inscenato online). Tuttavia, tutte le analisi che ho letto sull'attacco subito da OpenSSH tramite SystemD tramite XZ sono basate sulle stesse assunzioni che hanno reso possibile l'attacco. Alla base di questo castello di assunzioni c'è l'accettazione della enorme complessità degli stack applicativi mainstream, in cui nascondere una backdoor è facilissimo anche se (de)i sorgenti sono disponibili. Le libertà promesse dal software libero (e ancor più da quello opensource) sono sistematicamente vanificate dalla complessità che lo caratterizzano. Se una persona adulta non può leggere e comprendere interamente un software in (al massimo) un mese, quel software è irrimediabilmente vulnerabile e probabilmente compromesso. Il resto sono favolette consolatorie. Non è un problema dell'FLOSS. Non è un problema di autoconf. Non è nemmeno un problema di riproducibilità delle build. C'è un problema di sfruttamento degli sviluppatori volontari, ma risolverlo non risolverà il problema. Il problema è cibernetico e culturale, non tecnico o economico. Dovremmo ristudiare Wirth: https://www.projectoberon.net/ Giacomo [1] https://qoto.org/@Shamar/112195245691551523

April 12, 2024

Google Contract Shows Deal With Israel Defense Ministry | TIME

by J.C. DE MARTIN

https://time.com/6966102/google-contract-israel-defense-ministry-gaza-war/ (messaggio spedito in movimento - scusate brevità ed eventuali refusi)

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by 380°

Ciao Antonio, grazie per i link che non conoscevo! (ce ne saranno a decine di utili che ancora ignoro) Ai tuoi commenti rispondo rapidissimamente perché è facile ;-) Antonio <antonio(a)piumarossa.it> writes: > Ti assicuro che l'ho studiata, fidati sulla parola ;) ROTFL :-D [...] > Bene, lo "sviluppatore volontario Microsoft" è tale Andres Freund Sì e ovviamente ci sono ancora molte questioni aperte in merito ai tempi e modi nei quali ha rilevato e rivelato la backdoor... forse ci arriverò nella parte terza. Comunque ai fini della _sostanza_ della falla di sicurezza evidenziata da questo attacco la ritengo una questione /secondaria/, non perché ignoro che dietro la rivelazione potrebbe esserci una qualche macchinazione (anche secondaria), ma perché... chissenefrega? [...] > Qui un suo post del 2007 [1]. Per curiosità, per cosa ritieni che quel post sia interessante nel contesto di questa discussione? > Sulla faccenda c'è, quindi, anche da considerare la "lettura" di RMS e > gli altri [2][3] Ho dato una rapidissima occhiata ai due articoli (li leggerò con calma quando riuscirò) ma ho capito il senso... ...e sì, è ovvio che questa vicenda è usata, ancora una volta, per gettare fango ad-minchiam; per distratte? Non lo so, vedremo. Noi nel frattempo prendiamo nota ;-) Al volo ti dico che _non_ è un caso se ho scelto un articolo equilibrato intitolato «Backdoor su Xz: il problema è molto più grande, non è l'open source e non si risolve con un aggiornamento. Una storia incredibile». Chiunque abbia la incommensurabile faccia tosta di attribuire il fatto che la backdoor sia stata iniettata in OpenSSH perché "l'ecosistema" FLOSS non è sicuro mentre quello proprietario sì, ha solo voglia di rendersi ridicolo agli occhi della storia, anche se qualche beota probabilmente gli darà ascolto perché "autorevole". Ribadisco che "l'ecosistema" FLOSS consente di implementare tutti gli strumenti tecnici (in via di rapido sviluppo) e /sociali/ per evitare /anche/ simili attacchi, cosa che i /cultori/ del software proprietario possono solo sognarsi nei loro sogni erotici più spinti. Loving, 380° > [1] https://lore.kernel.org/lkml/200712020210.59041.andres@anarazel.de/ > [2] https://techrights.org/n/2024/03/31/Microsoft-Exchange-chaos-the-real-news.… > [3] https://techrights.org/n/2024/04/02/Richard_Stallman_Was_Right_and_What_Hap… -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

April 12, 2024

Disiscrizione

by Guildor

Buongiorno, vorrei gentilmente disiscrivermi dalla mailing list, purtroppo il link per farlo in autonomia non sembra funzionare. Grazie

April 12, 2024

22 aprile 2024 alle ore 16 Tavola rotonda"La protezione dei dati personali e la transizione digitale: le sfide attuali e future

by Mauro Alovisio

Gent.mi segnalo la tavola rotonda: "*La protezione dei dati personali e la transizione digitale: le sfide attuali e future" *che si terrà lunedì 22 aprile alle ore 16 a Torino presso aula magna del Campus Luigi Einaudi, Lungo Dora Siena 100 Saluti istituzionali : *Prof. Raffaele Caterina* , Direttore del Dipartimento di Giurisprudenza *Avv. Simona Grabbi,* Presidente dell’Ordine degli Avvocati di Torino *Dott.ssa Paola Zambon,* Referente GDPR - Ordine Dottori commercialisti ed esperti Contabili di Torino Dott. Fabrizio Bontempo, Presidente Ordine Consulenti del lavoro * Intervengono Prof. Francesco Pizzetti, Università degli Studi di Torino * *Prof. Sergio Foà*, Università degli Studi di Torino *Dott. Agostino Giglia*, componente dell'Autorità Garante per la protezione dei dati personali Avv.* Laura Marengo, *Unione industriali di Torino; *Avv. Mauro Alovisio*- Università degli Studi di Torino *Ing. Angelo Sacc*à direttore sistemi informativi Università di Torino E' gradita l'iscrizione tramite form onlineopen_in_new <https://forms.gle/HFet7kXSZ5jwLfLKA>. L'evento è accreditato per la formazione obbligatoria per gli avvocati *Durante la tavola rotonda sarà presentata la sesta edizione del corso:"Compliance dei dati e della protezione dei dati personali nella transizione digitale.* *Il corso sarà erogato sia in presenza che on line ed è accreditato per la formazione obbligatoria per avvocati* Qualora impossibilitati potete seguire on line Qui il sito dove saranno pubblicate nei prossimi giorni le informazioni su scadenze, costi iscrizioni https://www.giurisprudenza.unito.it/do/home.pl/View?doc=data_protection_off… Grazie per l'attenzione Un caro saluto Mauro Alovisio

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by Antonio

> Lungi da me voler dissuadere chiunque dall'aggiungere i propri commenti > a questo thread, faccio però a tutti una preghiera: siccome si tratta di > una questione relativamente complessa, sarebbe il caso che chi non > avesse avuto modo di studiare la questione "backdoor in XZ", Ti assicuro che l'ho studiata, fidati sulla parola ;) Qualche informazione in più, non prettamente tecnica ma necessaria, dato che in giro ci questi titoli ad effetto: "Come un volontario ha impedito a una backdoor di esporre i sistemi ..." o "Sviluppatore Microsoft salva Linux da una backdoor in xz". Bene, lo "sviluppatore volontario Microsoft" è tale Andres Freund che ha passato parte della sua giovane vita (38 anni) sul kernel Linux (discutendone in lista con Linus Torvalds e gli altri) e su PostgreSQL. Qui un suo post del 2007 [1]. Sulla faccenda c'è, quindi, anche da considerare la "lettura" di RMS e gli altri [2][3] A. [1] https://lore.kernel.org/lkml/200712020210.59041.andres@anarazel.de/ [2] https://techrights.org/n/2024/03/31/Microsoft-Exchange-chaos-the-real-news.… [3] https://techrights.org/n/2024/04/02/Richard_Stallman_Was_Right_and_What_Hap…

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by D. Davide Lamanna

On 4/12/24 09:49, 380° wrote: > Buongiorno, > > a chi è intervenuto (e interverrà) nel thread: grazie davvero per i > commenti che avete inviato, vi prometto che con calma vi risponderò ove > necessario, ma prima vorrei finire almeno la parte 2 della mia analisi e > ci vorrà ancora un po' di tempo (indefinito). > > Lungi da me voler dissuadere chiunque dall'aggiungere i propri commenti > a questo thread, faccio però a tutti una preghiera: siccome si tratta di > una questione relativamente complessa, sarebbe il caso che chi non > avesse avuto modo di studiare la questione "backdoor in XZ", anche > leggendo analisi altrui, si astenesse _momentaneamente_ dai commenti, > perché mancherebbero elementi importanti per formarsi un giudizio > completo in merito alla situazuione, alle sue cause e alle possibili > soluzioni a medio/lungo termine; sta succedendo anche a _superstar_ del > settore di sbagliare clamorosamente, credetemi. > > Infine, sapete che io sono il re degli OT ma in questo thread mi > piacerebbe ci concentrassimo sugli aspetti tecnici *e* ambientali > (sociali, economici, ecc.) che hanno reso possiblile questo _specifico_ > attacco che definirei: > > "targeted backdoor injection through build process subversion of a > library via supply chain attack by unfaithful authority" > > ...se non lo capite adesso, spero che dopo la parte 2 sarà più chiaro. > > Per ora aggiungo solo che non si tratta di una "banale" backdoor [1] e > nemmeno di un "banale" supply chain attack [2], perché per quel tipo di > attacchi l'ecosistema FLOSS ha già trovato _da_diverso_tempo_ una > *soluzione* tecnica, che alcune distribuzioni GNU/Linux et al stanno > cercando di attuare, risolvendo pazientemente le "asperità tecniche e > sociali" che stanno emergendo nelle fasi di _implementazione_ delle > soluzioni trovare. > > Alla prossima puntata :-) > > Loving, 380° > > [1] per esempio inserita direttamente nel codice della libreria > > [2] per esempio attuato infiltrandosi senza autorizzazione nel sistema > di distribuzione del *binario* > Grazie mille, 380°, veramente ben fatta. Attendo la seconda parte, allora. D. (null)

April 12, 2024

Re: [nexa] [CDT:L-1] (supply chain attack) rapido commento e preghiera.

by 380°

Buongiorno, a chi è intervenuto (e interverrà) nel thread: grazie davvero per i commenti che avete inviato, vi prometto che con calma vi risponderò ove necessario, ma prima vorrei finire almeno la parte 2 della mia analisi e ci vorrà ancora un po' di tempo (indefinito). Lungi da me voler dissuadere chiunque dall'aggiungere i propri commenti a questo thread, faccio però a tutti una preghiera: siccome si tratta di una questione relativamente complessa, sarebbe il caso che chi non avesse avuto modo di studiare la questione "backdoor in XZ", anche leggendo analisi altrui, si astenesse _momentaneamente_ dai commenti, perché mancherebbero elementi importanti per formarsi un giudizio completo in merito alla situazuione, alle sue cause e alle possibili soluzioni a medio/lungo termine; sta succedendo anche a _superstar_ del settore di sbagliare clamorosamente, credetemi. Infine, sapete che io sono il re degli OT ma in questo thread mi piacerebbe ci concentrassimo sugli aspetti tecnici *e* ambientali (sociali, economici, ecc.) che hanno reso possiblile questo _specifico_ attacco che definirei: "targeted backdoor injection through build process subversion of a library via supply chain attack by unfaithful authority" ...se non lo capite adesso, spero che dopo la parte 2 sarà più chiaro. Per ora aggiungo solo che non si tratta di una "banale" backdoor [1] e nemmeno di un "banale" supply chain attack [2], perché per quel tipo di attacchi l'ecosistema FLOSS ha già trovato _da_diverso_tempo_ una *soluzione* tecnica, che alcune distribuzioni GNU/Linux et al stanno cercando di attuare, risolvendo pazientemente le "asperità tecniche e sociali" che stanno emergendo nelle fasi di _implementazione_ delle soluzioni trovare. Alla prossima puntata :-) Loving, 380° [1] per esempio inserita direttamente nel codice della libreria [2] per esempio attuato infiltrandosi senza autorizzazione nel sistema di distribuzione del *binario* -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

April 12, 2024