nexa

By thread

nexa@server-nexa.polito.it

April 2024

38 participants
122 messages

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

by Marco A. Calamari

On gio, 2024-04-11 at 19:28 +0200, Stefano Quintarelli wrote: > una conclusione ptrebbe essere che forse siamo 4 a 1 a nostra insaputa perche' > all'attaccante basta avere ragione una volta sola mentre chi difende deve > avere ragione > sempre e se un cattivo ha avuto ragione, adesso potremmo averlo ospite in casa > a nostra > insaputa e lui potrebbe farci vedere sul tabellone 4 a 0 Tutto vero, certo, ma il problema è proprio questo. Nessuno userà le backdoor già impiantate per far soldi. Non le hanno impiantate normali criminali. Sono armi ben oliate ed immagazzinate ... pronte per essere usate per uno scopo pianificato con cura. La paranoia è una virtù. > On 11/04/24 19:20, Marco A. Calamari wrote: > > On gio, 2024-04-11 at 18:25 +0200, 380° wrote: > > > > > > Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" > > > non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, > > > iscrivetevi, se non lo siete già, alla newsletter di sicurezza della > > > distribuzione che state utilizzando (o rivolgetevi a un professionista). > > > > > > Buongiorno, > > > > > > per diversi giorni il mio alter ego si è occupato con una certa > > > _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta > > > scemando e può lavorare con più calma alle misure per mitigare questi > > > rischi... e lasciarmi scrivere qui in merito. > > > > Buonasera, > > > > malgrado la preoccupazione che chi ha letto il tuo contributo avrà > > sperabilmente provato, > > devo sottolineare che la situazione è molto peggiore di così. > > > > Infatti sembra che la comunità della security sia incapace di fare l'ultimo > > passo di questo > > ragionamento, e cioè che backdoor come quella di Xz, che non si è diffusa > > perché > > intercettata in tempo, **sono certamente già installate in altri > > software**. > > > > Ne scrivevo proprio qualche giorno fa qui. > > > > https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo… > > < > > https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo… > > > > > > > provo ad incollare il testo nel seguito. > > > > HTH. Marco, > > > > > > > > Cassandra Crossing/ Xz, Solarwinds e l’Armageddon prossimo venturo > > Marco A. L. Calamari > > > > (582) — Il sabotaggio della libreria Xz è stato sventato, ed ancora una > > volta i buoni > > hanno vinto. Ma siamo sicuri che altrove gli attacchi alla supply chain del > > software non > > siano riusciti senza che nessuno se ne sia accorto? > > > > 5 aprile 2024 — La realtà costringe Cassandra a prolungare ulteriormente la > > serie “Fine > > del Mondo” perché nuovi, gravissimi indizi emergono riguardo al fatto che le > > armi per > > l’Armageddon informatico prossimo venturo continuano ad accumularsi. > > > > E di nuovo, ventate di ottimismo, espresse anche da addetti ai lavori, si > > propagano in > > maniera tanto inesplicabile quanto pericolosa. Non certo per stupidità o per > > incompetenza; > > forse per desiderio di quieto vivere, forse per ingiustificato ottimismo. > > > > Ma per poter esprimere compiutamente ed in maniera comprensibile la sua > > tesi, Cassandra è > > come al solito costretta a riavvolgere il nastro e narrare un po’ di > > antefatti. > > > > Per fortuna ci basta riavvolgere solo al 2003, anno in cui viene portato > > alla luce il > > tentativo di introdurre una backdoor addirittura nel kernel di Linux. > > > > Un amministratore del repository dei sorgenti ufficiali si accorse che una > > modifica minima > > apportata ad una banale routine del kernel non appariva richiesta da > > nessuno. Cassandra > > non pretende che il C sia patrimonio dei suoi lettori, ma giusto al fine di > > illustrare la > > diabolicità della modifica, si tratta della variazione di un singolo > > carattere in una > > singola riga, cioè da > > > > if ((options == (__WCLONE|__WALL)) && (current->uid == 0)) > > > > a > > > > if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) > > > > la mancanza dell’ultimo “=” faceva si che, ad esempio, qualunque utente > > avesse usato il > > comando “kill” con un parametro opportuno (un valore a 16 bit) si sarebbe > > trovato > > “promosso” a root, e quindi avrebbe potuto prendere il completo controllo > > del server. > > > > La modifica fu annullata, l’infrastruttura dei server di compilazione fu > > piallata e > > ricostruita da zero, ed i sorgenti furono ricaricati da un backup. > > > > Buoni 1, Cattivi 0. > > > > Ma basta fare un avanti veloce al 2006 per trovare una ulteriore modifica > > diabolica nella > > libreria OpenSSL. Due semplici linee commentate diminuivano drasticamente > > l’entropia > > dell’RNG della libreria. Per farla anche qui semplice, facevano si che, ad > > esempio, il > > numero di differenti chiavi crittografiche generabili dalla libreria > > passasse da un valore > > praticamente infinito a 32767. Chi avesse conosciuto questo fatto e > > precalcolato le > > opportune chiavi avrebbe potuto forzare qualunque algoritmo crittografico > > che usasse > > OpenSSL (cioè praticamente tutti) con estrema facilità. > > > > Quando il problema fu scoperto e prontamente risolto, i suoi effetti non > > cessarono subito. > > Infatti ci vollero oltre due anni perché la maggioranza delle chiavi > > “deboli”, generate e > > diffuse per tutta internet venisse rimpiazzata, cosa che ha lasciato > > ulteriori due anni di > > tempo agli autori della malefatta per approfittare dei suoi effetti. > > > > Questo evento fu così sentito dai cronisti dell’epoca che addirittura il > > fumetto XKCD gli > > dedicò un’arguta vignetta. > > > > Ma andiamo avanti, perché purtroppo non c’è niente da ridere. > > > > Ci fu chi disse Buoni 2 — Cattivi 0 e palla al centro. > > > > Del calcolo di questo punteggio, che è un po’ il nocciolo del ragionamento > > di Cassandra, > > riparleremo alla fine di questa esternazione. > > > > Arriviamo rapidamente al 2020; un gruppo di criminali informatici al soldo > > di uno stato > > nazione attacca la rete di un produttore di software per la sicurezza > > informatica, > > probabilmente già nel 2018. Dopo aver violato la rete altera i server che > > compilavano il > > software destinato ad essere spedito ai clienti, in modo che includesse una > > backdoor. > > > > Non stiamo parlando di un software qualsiasi, Solarwinds è un sofisticato > > software per la > > sicurezza informatica, installato dalle più grandi organizzazioni con > > stringenti necessità > > di sicurezza, tra cui, ad esempio, una ventina di agenzie governative > > americane, fornitori > > di armamenti, grandi aziende informatiche e compagnia cantando. Si, anche in > > Italia. > > > > L’aggiornamento automatico di Solarwinds aveva quindi installato > > automaticamente una > > backdoor che rendeva semplicissimo violare le reti che lo utilizzavano; in > > questo modo > > migliaia di reti iperprotette si sono improvvisamente aperte ai criminali > > informatici che > > ne hanno potuto abusare a piacimento per anni. Quando l’attacco fu scoperto > > (perché di > > attacco si tratta), il principale problema per le organizzazioni colpite fu > > di capire se > > erano o no state violate, perché gli attaccanti erano del tipo più > > pericoloso, quelli > > bravi, che non si fanno scoprire e che è difficilissimo trovare e scacciare. > > > > E finalmente arriviamo al 2024, ad oggi, anzi a due settimane fa, ed > > all’attacco alla > > libreria Xz. > > > > Un dipendente Microsoft che utilizzava OpenSSL (si, di nuovo lei) si accorge > > che la nuova > > versione ci mette 500 millisecondi in più a compere certe operazioni > > rispetto alla > > versione precedente. Siccome evidentemente nella sua vita non aveva di > > meglio da fare e > > giudicava importante questo problema, si mette a controllare i codici > > sorgenti per > > cercarne il motivo. Con suo stupore si accorge che la nuova versione della > > libreria > > OpenSSL contiene un file binario proveniente da un’altra libreria, per > > l’esattezza Xz che > > è la libreria che si occupa di comprimere e decomprimere i file; si, proprio > > quella con > > cui zippate i vostri PDF, che lo sappiate o meno. > > > > Si accorge con orrore che questa modifica permette, a chi possiede certe > > chiavi > > crittografiche, di iniettare ed eseguire qualunque programma direttamente > > nel kernel del > > sistema operativo, e di far succedere qualsiasi cosa; dal prendere il > > controllo completo > > del sistema a distruggere rapidamente e completamente tutti i server > > compromessi. > > > > L’analisi retrospettiva degli avvenimenti ha rivelato che due anni prima uno > > sviluppatore > > anonimo aveva iniziato a proporre modifiche alla libreria Xz, che erano > > ragionevoli e > > quindi erano state accettate del suo amministratore, e poi a farsi accettare > > come > > co-amministratore della libreria stessa. Aveva poi lentamente sovvertito il > > sistema di > > compilazione della libreria stessa, inserendovi il codice malevolo destinato > > a finire > > nella libreria OpenSSL, e contemporaneamente svolgendo una sofisticata > > azione di > > ingegneria sociale nei confronti di chi avrebbe potuto controllare le sue > > modifiche in > > modo tale che queste verifiche non fossero fatte. > > > > Poi, quando la libreria infettata ha cominciato a propagarsi sui primi > > server, uno di essi > > è stato quello del benedetto dipendente Microsoft con tanto tempo libero, > > che non > > ringrazieremo mai abbastanza e che meriterebbe un monumento. > > > > Se questo scarno riassunto non vi paresse abbastanza, potete divertirvi > > ascoltando questo > > podcast in cui due titani della scena hacker italiana degli anni ’90 > > discutono, > > approfonditamente e scherzosamente, della faccenda, condividendo anche un > > giudizio > > ottimistico per il futuro. > > > > Quindi Buoni 3 — Cattivi 0 e palla al centro? > > > > Bene, questa valutazione è quella che ha accompagnato questi terrificanti > > eventi, venuti > > alla luce sempre per fortuna, e prima che potessero causare danni > > catastrofici. In effetti > > Solarwind ha davvero causato danni economici rilevantissimi e danni > > derivanti da furti di > > dati e da attività spionistiche non precisabili, ma dovrebbe aver spinto la > > comunità > > informatica mondiale ad attivarsi contro questo nuovo tipo di attacchi > > informatici. > > > > Quindi Buoni 4 — Cattivi 0?? > > > > Ed arriviamo alle conclusioni, probabilmente ormai chiarissime ai 24 > > informatissimi > > lettori di Cassandra. > > > > Per tutte le divinità mai adorate dagli umani, da Astarte a Zaratustra, > > inclusi Manitù, > > Cthulhu e Yog-Setoth, è possibile che nessuno pensi a tutti gli attacchi di > > questa portata > > che non sono mai stati rilevati? Quelli in cui nessun dipendente insonne è > > inciampato, che > > nessun amministratore di sistema curioso ha mai rilevato? > > > > Ma davvero ci sono addetti ai lavori che credono che i buoni continuino a > > segnare e che i > > cattivi siano costretti nella loro metà campo? > > > > Davvero qualcuno può pensare che gli stati-nazione, i produttori di armi, i > > grandi e > > piccoli gruppi criminali e le mafie non stiano accumulando, in grandi e > > piccoli arsenali, > > queste “modifiche” al software che fa funzionare il mondo, queste armi > > informatiche che > > talvolta sono state anche testate od utilizzate su scala ridotta o con > > conseguenze > > circoscritte (i nomi SQL Slammer e Stuxnet non vi dicono niente?). > > > > Cassandra è sempre stata andreottiana nell’animo, e mai come in questo caso > > sente il > > dovere di invitare gli ottimisti a riconsiderare le proprie posizioni, non > > per un > > principio di precauzione, ma per puro e semplice realismo. > > > > L’Armageddon della prima guerra informatica mondiale è certamente, e ripeto > > certamente in > > fase di avanzata realizzazione. Poi non dite che non vi avevo avvertito. > > > > -- > > > > Marco A. Calamari > > <marcoc_maillist(a)marcoc.it <mailto:marcoc_maillist@marcoc.it>> > > > > _______________________________________________ > > nexa mailing list > > nexa(a)server-nexa.polito.it > > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 11, 2024

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

by Stefano Quintarelli

una conclusione ptrebbe essere che forse siamo 4 a 1 a nostra insaputa perche' all'attaccante basta avere ragione una volta sola mentre chi difende deve avere ragione sempre e se un cattivo ha avuto ragione, adesso potremmo averlo ospite in casa a nostra insaputa e lui potrebbe farci vedere sul tabellone 4 a 0 On 11/04/24 19:20, Marco A. Calamari wrote: > On gio, 2024-04-11 at 18:25 +0200, 380° wrote: >> >> Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" >> non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, >> iscrivetevi, se non lo siete già, alla newsletter di sicurezza della >> distribuzione che state utilizzando (o rivolgetevi a un professionista). >> >> Buongiorno, >> >> per diversi giorni il mio alter ego si è occupato con una certa >> _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta >> scemando e può lavorare con più calma alle misure per mitigare questi >> rischi... e lasciarmi scrivere qui in merito. > > Buonasera, > > malgrado la preoccupazione che chi ha letto il tuo contributo avrà sperabilmente provato, > devo sottolineare che la situazione è molto peggiore di così. > > Infatti sembra che la comunità della security sia incapace di fare l'ultimo passo di questo > ragionamento, e cioè che backdoor come quella di Xz, che non si è diffusa perché > intercettata in tempo, **sono certamente già installate in altri software**. > > Ne scrivevo proprio qualche giorno fa qui. > > https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo… <https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo…> > > provo ad incollare il testo nel seguito. > > HTH. Marco, > > > > Cassandra Crossing/ Xz, Solarwinds e l’Armageddon prossimo venturo > Marco A. L. Calamari > > (582) — Il sabotaggio della libreria Xz è stato sventato, ed ancora una volta i buoni > hanno vinto. Ma siamo sicuri che altrove gli attacchi alla supply chain del software non > siano riusciti senza che nessuno se ne sia accorto? > > 5 aprile 2024 — La realtà costringe Cassandra a prolungare ulteriormente la serie “Fine > del Mondo” perché nuovi, gravissimi indizi emergono riguardo al fatto che le armi per > l’Armageddon informatico prossimo venturo continuano ad accumularsi. > > E di nuovo, ventate di ottimismo, espresse anche da addetti ai lavori, si propagano in > maniera tanto inesplicabile quanto pericolosa. Non certo per stupidità o per incompetenza; > forse per desiderio di quieto vivere, forse per ingiustificato ottimismo. > > Ma per poter esprimere compiutamente ed in maniera comprensibile la sua tesi, Cassandra è > come al solito costretta a riavvolgere il nastro e narrare un po’ di antefatti. > > Per fortuna ci basta riavvolgere solo al 2003, anno in cui viene portato alla luce il > tentativo di introdurre una backdoor addirittura nel kernel di Linux. > > Un amministratore del repository dei sorgenti ufficiali si accorse che una modifica minima > apportata ad una banale routine del kernel non appariva richiesta da nessuno. Cassandra > non pretende che il C sia patrimonio dei suoi lettori, ma giusto al fine di illustrare la > diabolicità della modifica, si tratta della variazione di un singolo carattere in una > singola riga, cioè da > > if ((options == (__WCLONE|__WALL)) && (current->uid == 0)) > > a > > if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) > > la mancanza dell’ultimo “=” faceva si che, ad esempio, qualunque utente avesse usato il > comando “kill” con un parametro opportuno (un valore a 16 bit) si sarebbe trovato > “promosso” a root, e quindi avrebbe potuto prendere il completo controllo del server. > > La modifica fu annullata, l’infrastruttura dei server di compilazione fu piallata e > ricostruita da zero, ed i sorgenti furono ricaricati da un backup. > > Buoni 1, Cattivi 0. > > Ma basta fare un avanti veloce al 2006 per trovare una ulteriore modifica diabolica nella > libreria OpenSSL. Due semplici linee commentate diminuivano drasticamente l’entropia > dell’RNG della libreria. Per farla anche qui semplice, facevano si che, ad esempio, il > numero di differenti chiavi crittografiche generabili dalla libreria passasse da un valore > praticamente infinito a 32767. Chi avesse conosciuto questo fatto e precalcolato le > opportune chiavi avrebbe potuto forzare qualunque algoritmo crittografico che usasse > OpenSSL (cioè praticamente tutti) con estrema facilità. > > Quando il problema fu scoperto e prontamente risolto, i suoi effetti non cessarono subito. > Infatti ci vollero oltre due anni perché la maggioranza delle chiavi “deboli”, generate e > diffuse per tutta internet venisse rimpiazzata, cosa che ha lasciato ulteriori due anni di > tempo agli autori della malefatta per approfittare dei suoi effetti. > > Questo evento fu così sentito dai cronisti dell’epoca che addirittura il fumetto XKCD gli > dedicò un’arguta vignetta. > > Ma andiamo avanti, perché purtroppo non c’è niente da ridere. > > Ci fu chi disse Buoni 2 — Cattivi 0 e palla al centro. > > Del calcolo di questo punteggio, che è un po’ il nocciolo del ragionamento di Cassandra, > riparleremo alla fine di questa esternazione. > > Arriviamo rapidamente al 2020; un gruppo di criminali informatici al soldo di uno stato > nazione attacca la rete di un produttore di software per la sicurezza informatica, > probabilmente già nel 2018. Dopo aver violato la rete altera i server che compilavano il > software destinato ad essere spedito ai clienti, in modo che includesse una backdoor. > > Non stiamo parlando di un software qualsiasi, Solarwinds è un sofisticato software per la > sicurezza informatica, installato dalle più grandi organizzazioni con stringenti necessità > di sicurezza, tra cui, ad esempio, una ventina di agenzie governative americane, fornitori > di armamenti, grandi aziende informatiche e compagnia cantando. Si, anche in Italia. > > L’aggiornamento automatico di Solarwinds aveva quindi installato automaticamente una > backdoor che rendeva semplicissimo violare le reti che lo utilizzavano; in questo modo > migliaia di reti iperprotette si sono improvvisamente aperte ai criminali informatici che > ne hanno potuto abusare a piacimento per anni. Quando l’attacco fu scoperto (perché di > attacco si tratta), il principale problema per le organizzazioni colpite fu di capire se > erano o no state violate, perché gli attaccanti erano del tipo più pericoloso, quelli > bravi, che non si fanno scoprire e che è difficilissimo trovare e scacciare. > > E finalmente arriviamo al 2024, ad oggi, anzi a due settimane fa, ed all’attacco alla > libreria Xz. > > Un dipendente Microsoft che utilizzava OpenSSL (si, di nuovo lei) si accorge che la nuova > versione ci mette 500 millisecondi in più a compere certe operazioni rispetto alla > versione precedente. Siccome evidentemente nella sua vita non aveva di meglio da fare e > giudicava importante questo problema, si mette a controllare i codici sorgenti per > cercarne il motivo. Con suo stupore si accorge che la nuova versione della libreria > OpenSSL contiene un file binario proveniente da un’altra libreria, per l’esattezza Xz che > è la libreria che si occupa di comprimere e decomprimere i file; si, proprio quella con > cui zippate i vostri PDF, che lo sappiate o meno. > > Si accorge con orrore che questa modifica permette, a chi possiede certe chiavi > crittografiche, di iniettare ed eseguire qualunque programma direttamente nel kernel del > sistema operativo, e di far succedere qualsiasi cosa; dal prendere il controllo completo > del sistema a distruggere rapidamente e completamente tutti i server compromessi. > > L’analisi retrospettiva degli avvenimenti ha rivelato che due anni prima uno sviluppatore > anonimo aveva iniziato a proporre modifiche alla libreria Xz, che erano ragionevoli e > quindi erano state accettate del suo amministratore, e poi a farsi accettare come > co-amministratore della libreria stessa. Aveva poi lentamente sovvertito il sistema di > compilazione della libreria stessa, inserendovi il codice malevolo destinato a finire > nella libreria OpenSSL, e contemporaneamente svolgendo una sofisticata azione di > ingegneria sociale nei confronti di chi avrebbe potuto controllare le sue modifiche in > modo tale che queste verifiche non fossero fatte. > > Poi, quando la libreria infettata ha cominciato a propagarsi sui primi server, uno di essi > è stato quello del benedetto dipendente Microsoft con tanto tempo libero, che non > ringrazieremo mai abbastanza e che meriterebbe un monumento. > > Se questo scarno riassunto non vi paresse abbastanza, potete divertirvi ascoltando questo > podcast in cui due titani della scena hacker italiana degli anni ’90 discutono, > approfonditamente e scherzosamente, della faccenda, condividendo anche un giudizio > ottimistico per il futuro. > > Quindi Buoni 3 — Cattivi 0 e palla al centro? > > Bene, questa valutazione è quella che ha accompagnato questi terrificanti eventi, venuti > alla luce sempre per fortuna, e prima che potessero causare danni catastrofici. In effetti > Solarwind ha davvero causato danni economici rilevantissimi e danni derivanti da furti di > dati e da attività spionistiche non precisabili, ma dovrebbe aver spinto la comunità > informatica mondiale ad attivarsi contro questo nuovo tipo di attacchi informatici. > > Quindi Buoni 4 — Cattivi 0?? > > Ed arriviamo alle conclusioni, probabilmente ormai chiarissime ai 24 informatissimi > lettori di Cassandra. > > Per tutte le divinità mai adorate dagli umani, da Astarte a Zaratustra, inclusi Manitù, > Cthulhu e Yog-Setoth, è possibile che nessuno pensi a tutti gli attacchi di questa portata > che non sono mai stati rilevati? Quelli in cui nessun dipendente insonne è inciampato, che > nessun amministratore di sistema curioso ha mai rilevato? > > Ma davvero ci sono addetti ai lavori che credono che i buoni continuino a segnare e che i > cattivi siano costretti nella loro metà campo? > > Davvero qualcuno può pensare che gli stati-nazione, i produttori di armi, i grandi e > piccoli gruppi criminali e le mafie non stiano accumulando, in grandi e piccoli arsenali, > queste “modifiche” al software che fa funzionare il mondo, queste armi informatiche che > talvolta sono state anche testate od utilizzate su scala ridotta o con conseguenze > circoscritte (i nomi SQL Slammer e Stuxnet non vi dicono niente?). > > Cassandra è sempre stata andreottiana nell’animo, e mai come in questo caso sente il > dovere di invitare gli ottimisti a riconsiderare le proprie posizioni, non per un > principio di precauzione, ma per puro e semplice realismo. > > L’Armageddon della prima guerra informatica mondiale è certamente, e ripeto certamente in > fase di avanzata realizzazione. Poi non dite che non vi avevo avvertito. > > -- > > Marco A. Calamari <marcoc_maillist(a)marcoc.it <mailto:marcoc_maillist@marcoc.it>> > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 11, 2024

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

by Marco A. Calamari

On gio, 2024-04-11 at 18:25 +0200, 380° wrote: > > Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" > non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, > iscrivetevi, se non lo siete già, alla newsletter di sicurezza della > distribuzione che state utilizzando (o rivolgetevi a un professionista). > > Buongiorno, > > per diversi giorni il mio alter ego si è occupato con una certa > _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta > scemando e può lavorare con più calma alle misure per mitigare questi > rischi... e lasciarmi scrivere qui in merito. Buonasera, malgrado la preoccupazione che chi ha letto il tuo contributo avrà sperabilmente provato, devo sottolineare che la situazione è molto peggiore di così. Infatti sembra che la comunità della security sia incapace di fare l'ultimo passo di questo ragionamento, e cioè che backdoor come quella di Xz, che non si è diffusa perché intercettata in tempo, **sono certamente già installate in altri software**. Ne scrivevo proprio qualche giorno fa qui. https://medium.com/@calamarim/cassandra-crossing-xz-solarwinds-e-larmageddo… provo ad incollare il testo nel seguito. HTH. Marco, Cassandra Crossing/ Xz, Solarwinds e l’Armageddon prossimo venturo Marco A. L. Calamari (582) — Il sabotaggio della libreria Xz è stato sventato, ed ancora una volta i buoni hanno vinto. Ma siamo sicuri che altrove gli attacchi alla supply chain del software non siano riusciti senza che nessuno se ne sia accorto? 5 aprile 2024 — La realtà costringe Cassandra a prolungare ulteriormente la serie “Fine del Mondo” perché nuovi, gravissimi indizi emergono riguardo al fatto che le armi per l’Armageddon informatico prossimo venturo continuano ad accumularsi. E di nuovo, ventate di ottimismo, espresse anche da addetti ai lavori, si propagano in maniera tanto inesplicabile quanto pericolosa. Non certo per stupidità o per incompetenza; forse per desiderio di quieto vivere, forse per ingiustificato ottimismo. Ma per poter esprimere compiutamente ed in maniera comprensibile la sua tesi, Cassandra è come al solito costretta a riavvolgere il nastro e narrare un po’ di antefatti. Per fortuna ci basta riavvolgere solo al 2003, anno in cui viene portato alla luce il tentativo di introdurre una backdoor addirittura nel kernel di Linux. Un amministratore del repository dei sorgenti ufficiali si accorse che una modifica minima apportata ad una banale routine del kernel non appariva richiesta da nessuno. Cassandra non pretende che il C sia patrimonio dei suoi lettori, ma giusto al fine di illustrare la diabolicità della modifica, si tratta della variazione di un singolo carattere in una singola riga, cioè da if ((options == (__WCLONE|__WALL)) && (current->uid == 0)) a if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) la mancanza dell’ultimo “=” faceva si che, ad esempio, qualunque utente avesse usato il comando “kill” con un parametro opportuno (un valore a 16 bit) si sarebbe trovato “promosso” a root, e quindi avrebbe potuto prendere il completo controllo del server. La modifica fu annullata, l’infrastruttura dei server di compilazione fu piallata e ricostruita da zero, ed i sorgenti furono ricaricati da un backup. Buoni 1, Cattivi 0. Ma basta fare un avanti veloce al 2006 per trovare una ulteriore modifica diabolica nella libreria OpenSSL. Due semplici linee commentate diminuivano drasticamente l’entropia dell’RNG della libreria. Per farla anche qui semplice, facevano si che, ad esempio, il numero di differenti chiavi crittografiche generabili dalla libreria passasse da un valore praticamente infinito a 32767. Chi avesse conosciuto questo fatto e precalcolato le opportune chiavi avrebbe potuto forzare qualunque algoritmo crittografico che usasse OpenSSL (cioè praticamente tutti) con estrema facilità. Quando il problema fu scoperto e prontamente risolto, i suoi effetti non cessarono subito. Infatti ci vollero oltre due anni perché la maggioranza delle chiavi “deboli”, generate e diffuse per tutta internet venisse rimpiazzata, cosa che ha lasciato ulteriori due anni di tempo agli autori della malefatta per approfittare dei suoi effetti. Questo evento fu così sentito dai cronisti dell’epoca che addirittura il fumetto XKCD gli dedicò un’arguta vignetta. Ma andiamo avanti, perché purtroppo non c’è niente da ridere. Ci fu chi disse Buoni 2 — Cattivi 0 e palla al centro. Del calcolo di questo punteggio, che è un po’ il nocciolo del ragionamento di Cassandra, riparleremo alla fine di questa esternazione. Arriviamo rapidamente al 2020; un gruppo di criminali informatici al soldo di uno stato nazione attacca la rete di un produttore di software per la sicurezza informatica, probabilmente già nel 2018. Dopo aver violato la rete altera i server che compilavano il software destinato ad essere spedito ai clienti, in modo che includesse una backdoor. Non stiamo parlando di un software qualsiasi, Solarwinds è un sofisticato software per la sicurezza informatica, installato dalle più grandi organizzazioni con stringenti necessità di sicurezza, tra cui, ad esempio, una ventina di agenzie governative americane, fornitori di armamenti, grandi aziende informatiche e compagnia cantando. Si, anche in Italia. L’aggiornamento automatico di Solarwinds aveva quindi installato automaticamente una backdoor che rendeva semplicissimo violare le reti che lo utilizzavano; in questo modo migliaia di reti iperprotette si sono improvvisamente aperte ai criminali informatici che ne hanno potuto abusare a piacimento per anni. Quando l’attacco fu scoperto (perché di attacco si tratta), il principale problema per le organizzazioni colpite fu di capire se erano o no state violate, perché gli attaccanti erano del tipo più pericoloso, quelli bravi, che non si fanno scoprire e che è difficilissimo trovare e scacciare. E finalmente arriviamo al 2024, ad oggi, anzi a due settimane fa, ed all’attacco alla libreria Xz. Un dipendente Microsoft che utilizzava OpenSSL (si, di nuovo lei) si accorge che la nuova versione ci mette 500 millisecondi in più a compere certe operazioni rispetto alla versione precedente. Siccome evidentemente nella sua vita non aveva di meglio da fare e giudicava importante questo problema, si mette a controllare i codici sorgenti per cercarne il motivo. Con suo stupore si accorge che la nuova versione della libreria OpenSSL contiene un file binario proveniente da un’altra libreria, per l’esattezza Xz che è la libreria che si occupa di comprimere e decomprimere i file; si, proprio quella con cui zippate i vostri PDF, che lo sappiate o meno. Si accorge con orrore che questa modifica permette, a chi possiede certe chiavi crittografiche, di iniettare ed eseguire qualunque programma direttamente nel kernel del sistema operativo, e di far succedere qualsiasi cosa; dal prendere il controllo completo del sistema a distruggere rapidamente e completamente tutti i server compromessi. L’analisi retrospettiva degli avvenimenti ha rivelato che due anni prima uno sviluppatore anonimo aveva iniziato a proporre modifiche alla libreria Xz, che erano ragionevoli e quindi erano state accettate del suo amministratore, e poi a farsi accettare come co-amministratore della libreria stessa. Aveva poi lentamente sovvertito il sistema di compilazione della libreria stessa, inserendovi il codice malevolo destinato a finire nella libreria OpenSSL, e contemporaneamente svolgendo una sofisticata azione di ingegneria sociale nei confronti di chi avrebbe potuto controllare le sue modifiche in modo tale che queste verifiche non fossero fatte. Poi, quando la libreria infettata ha cominciato a propagarsi sui primi server, uno di essi è stato quello del benedetto dipendente Microsoft con tanto tempo libero, che non ringrazieremo mai abbastanza e che meriterebbe un monumento. Se questo scarno riassunto non vi paresse abbastanza, potete divertirvi ascoltando questo podcast in cui due titani della scena hacker italiana degli anni ’90 discutono, approfonditamente e scherzosamente, della faccenda, condividendo anche un giudizio ottimistico per il futuro. Quindi Buoni 3 — Cattivi 0 e palla al centro? Bene, questa valutazione è quella che ha accompagnato questi terrificanti eventi, venuti alla luce sempre per fortuna, e prima che potessero causare danni catastrofici. In effetti Solarwind ha davvero causato danni economici rilevantissimi e danni derivanti da furti di dati e da attività spionistiche non precisabili, ma dovrebbe aver spinto la comunità informatica mondiale ad attivarsi contro questo nuovo tipo di attacchi informatici. Quindi Buoni 4 — Cattivi 0?? Ed arriviamo alle conclusioni, probabilmente ormai chiarissime ai 24 informatissimi lettori di Cassandra. Per tutte le divinità mai adorate dagli umani, da Astarte a Zaratustra, inclusi Manitù, Cthulhu e Yog-Setoth, è possibile che nessuno pensi a tutti gli attacchi di questa portata che non sono mai stati rilevati? Quelli in cui nessun dipendente insonne è inciampato, che nessun amministratore di sistema curioso ha mai rilevato? Ma davvero ci sono addetti ai lavori che credono che i buoni continuino a segnare e che i cattivi siano costretti nella loro metà campo? Davvero qualcuno può pensare che gli stati-nazione, i produttori di armi, i grandi e piccoli gruppi criminali e le mafie non stiano accumulando, in grandi e piccoli arsenali, queste “modifiche” al software che fa funzionare il mondo, queste armi informatiche che talvolta sono state anche testate od utilizzate su scala ridotta o con conseguenze circoscritte (i nomi SQL Slammer e Stuxnet non vi dicono niente?). Cassandra è sempre stata andreottiana nell’animo, e mai come in questo caso sente il dovere di invitare gli ottimisti a riconsiderare le proprie posizioni, non per un principio di precauzione, ma per puro e semplice realismo. L’Armageddon della prima guerra informatica mondiale è certamente, e ripeto certamente in fase di avanzata realizzazione. Poi non dite che non vi avevo avvertito. -- Marco A. Calamari <marcoc_maillist(a)marcoc.it>

April 11, 2024

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

by Italo Vignoli

Unfortunately, in today's work environment - where many people are at home and rely on network-based services not only for work but also for entertainment (Netflix and the like) - the infrastructure is under stress and the download may fail several times. When you click the yellow DOWNLOAD button, the download starts in the background without any visible activity on your screen. We suggest you open the DOWNLOAD page in your browser to check the status. Please do not close the browser until you are sure the download is complete. If the download does not start, please try a different server. To change servers, click on the INFO link just below the yellow DOWNLOAD button and select a server from the list that appears on the page that opens when you click on the INFO link. Please note that you can retry the download as many times as you like, as long as you do not close the browser window before the download is complete. You can ignore the donation request, as donations are optional and help us keep the project alive. If all goes well, when the download is complete, a window will open asking you to choose whether to run the installer or save the file to your hard drive. Please choose the second option and save the file to your DOWNLOADS folder. Then open the DOWNLOADS folder and double-click on the file (the name starts with LibreOffice and ends with .MSI on Windows and .DMG on MacOS). Follow the on-screen instructions carefully until the end of the installation process. If everything goes well, LibreOffice will be installed correctly and will appear in your menu (for Windows) or in your Applications folder (for MacOS). Please do not use torrents as they are not reliable (as of today). Sorry for the long message. I hope this helps. Best regards. On 11/04/24 19:13, maurizio lana wrote: > Marco Calamari in Cassandra ne ha parlato qualche giorno fa. > "dignitosa coscienza e netta", lui non lo ha detto qui. > Maurizio > > Il 11/04/24 18:25, 380° ha scritto: >> Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" >> non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, >> iscrivetevi, se non lo siete già, alla newsletter di sicurezza della >> distribuzione che state utilizzando (o rivolgetevi a un professionista). >> >> Buongiorno, >> >> per diversi giorni il mio alter ego si è occupato con una certa >> _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta >> scemando e può lavorare con più calma alle misure per mitigare questi >> rischi... e lasciarmi scrivere qui in merito. >> >> Qualcuno in lista almeno ne avrà sentito palare ma forse la maggior >> parte ancora non sa che il 29 Marzo 2024 è stato scoperto il peggior >> supply chain attack ad oggi conosciuto. >> >> La vulnerabilità è tecnicamente conosciuta come CVE-2024-3094 e il NIST >> gli assegna un punteggio di 10 (su 10), ma potrebbe benissimo essere 10 >> cum laude:https://nvd.nist.gov/vuln/detail/CVE-2024-3094 >> >> I dettagli tecnici e _sistemistici_ sono relativamente (poco) complessi >> e NON trascurabili per poter avere una chiara e precisa comprensione del >> /modus vivendi/ ma soprattutto del /modus operandi/ che ha reso >> possibile questo attacco... "nucleare". >> >> In merito si stanno scrivendo fiumi di parole, molte delle quali a >> sproposito, anche da parte di "esperti del settore", come purtroppo >> accade quando si tratta di "cose complesse" (non complicate!) di >> informatica ;-(. >> >> In questa prima parte, come /introduzione/ alla questione vi consiglio >> un articolo che ritengo meritevole. >> >> Prima però voglio sottolineare una opportuna quanto agghiacciante >> considerazione di Bruce Schneier: >> >> https://www.schneier.com/blog/archives/2024/04/xz-utils-backdoor.html >> >> --8<---------------cut here---------------start------------->8--- >> >> Given how lucky we were to detect this one, I believe this kind of >> operation has been successful in the past. >> >> --8<---------------cut here---------------end--------------->8--- >> >> e una totalmente inopportuna e altrettanto superficiale: >> >> --8<---------------cut here---------------start------------->8--- >> >> We simply have to stop building our critical national infrastructure on >> top of random software libraries managed by lone unpaid distracted—or >> worse—individuals. >> >> --8<---------------cut here---------------end--------------->8--- >> >> Ecco finalmente l'articolo introduttivo: >> >> https://www.insicurezzadigitale.com/backdoor-su-xz-il-problema-e-molto-piu-… >> >> «Backdoor su Xz: il problema è molto più grande, non è l'open source e >> non si risolve con un aggiornamento. Una storia incredibile» >> >> Dario Fadda, 2024-04-11 >> >> --8<---------------cut here---------------start------------->8--- >> >> Mondo Linux in allarme da alcuni giorni, grande eco per la >> vulnerabilità rilevata su Xz il 29 marzo appena passato. Una backdoor >> installata sul codice open source della libreria largamente utilizzata >> per la compressione di dati che utilizza l'algoritmo [lzma], che >> *permette di eseguire codice da remoto su un server SSH* senza averne >> l'autenticazione. >> >> Questi sono i fatti, ma il contenuto di questo articolo vuole >> rispondere ad altre domande che sorgono naturalmente: come fa una >> utility di compressione ad agire su SSH? Chi ha installato questa >> backdoor e come ci è riuscito? >> >> Proviamo a vederci chiaro, ma di sicuro premetto che le favolette >> dell'instabilità di un progetto open source e dell'hacker annoiato >> nella propria stanza, non reggono. >> >> [lzma]<https://it.wikipedia.org/wiki/Algoritmo_Lempel-Ziv-Markov> >> >> Come funziona la backdoor su Xz? >> ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ >> >> Non mi dilungherò in analisi dettagliate e tecniche sul funzionamento >> di questa backdoor, già ampiamente dibattute ([qui] e [qui]), ma >> giusto due righe per chiarirne il concetto base. >> >> Vista l'efficienza della libreria Xz, è da sempre utilizzata da molti >> altri software che necessitano di effettuare compressione dati >> (soprattutto nella gestione dei loro pacchetti). Tra gli utilizzatori >> c'è pure OpenSSH, il software più utilizzato per effettuare >> connessioni sicure tra client e server (gestire da remoto la shell, >> quindi la completa amministrazione, di un computer disposto altrove) >> via SSH. Il pacchetto OpenSSH non ha però la diretta dipendenza della >> libreria Xz. Qui dobbiamo prestare attenzione a questo passaggio, >> perché è il primo punto di complicazione di *come è stato congegnato >> l'atterraggio verso SSH* /senza farsi beccare/: OpenSSH ha una >> funzionalità di notifica sui sistemi operativi che utilizzano >> *SystemD* che è governata da una libreria “libsystemd” che a sua volta >> utilizza una seconda libreria che si chiama “liblzma” che è parte del >> progetto Xz! Un bel giro, per iniettare del codice malevolo ed >> arrivare a destinazione, sicuramente niente di /fatto in casa/. >> >> [qui] >> <https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27> >> >> [qui]<https://gynvael.coldwind.pl/?lang=en&id=782> >> >> Come è stato possibile? >> ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ >> >> La backdoor Xz è stata la parte finale di una campagna durata due anni >> di attività, *si tratta di operazioni di human intelligence* molto >> elaborate e che richiedono tempo e persone. Due anni di /lavoro/ per >> avere una backdoor aperta circa tre settimane prima che venga >> rilevata. C'è stato un approccio che è durato mesi prima che il >> *personaggio di Jia Tan* (JiaT75 questo lo pseudonimo di chi ha >> diffuso il codice malevolo all'interno del progetto Xz originale) >> fosse ben posizionato per ricevere un ruolo di fiducia nel progetto, >> da parte di chi segue la manutenzione diretta ( /Lasse Collin/ è >> invece il suo nome). >> >> L'account su GitHub di *Jia Tan viene registrato nel 2021*. Non >> opererà però subito su Xz, ma inizia scrivendo un commit per un altro >> pacchetto open source “libarchive”. Con questo commit aggiunge una >> vulnerabilità pure li che nessuno discute mai e che quindi, ad oggi >> potrebbe far considerare *non sicuro pure libarchive*. >> >> In sintesi, Jia Tan e altri attori hanno lavorato per introdurre una >> backdoor nel progetto XZ, utilizzando varie tattiche per aumentare il >> controllo sul progetto e cercando di far includere la versione >> compromessa in diverse distribuzioni di Linux. >> >> La storia >> ╌╌╌╌╌╌╌╌╌ >> >> Subito dopo i fatti del 2021 appena descritti è un susseguirsi di >> attività che portano fino ai giorni attuali. >> >> [...] >> >> La gravità >> ╌╌╌╌╌╌╌╌╌╌╌ >> >> Da come si sono articolati gli eventi, possiamo comprendere bene la >> gravità della situazione e di come l'organizzazione dietro questo >> attacco, sia enormemente organizzata. Va ricordato che la versione >> vulnerabile di Xz è rimasta operativa per [tre settimane] circa (dal 9 >> marzo 2024), in ogni caso è plausibile che gli sforzi di questi due >> anni per condurre l'operazione, mirino ai ritardi negli aggiornamenti, >> prima che tutti i sistemi coinvolti (vista la diffusione dello >> strumento Xz), vengano raggiunti dagli aggiornamenti necessari per >> sanare il problema. >> >> Il modus operandi di questa cronologia di eventi, è il tipico stile di >> operazione di human intelligence che punta a *sconvolgere il >> bersaglio* (Lasse Collin, mantenitore del progetto), dal punto di >> vista psicologico (capendo su che leve operare): ecco cosa scrive >> Lasse in una mailing-list nel 2022 quando aumentavano le pressioni per >> far aggiungere un altro contributore al progetto Xz. >> >> [immagine del messaggio: >> https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html] >> >> Sottolinei un problema che qualcuno non è in grado di risolvere, ti >> fai spalleggiare da altri utenti (finti, della tua organizzazione >> malevola), e ti rendi disponibile a risolverlo. È il modo migliore per >> entrare nella cerchia della fiducia, di un debole preso dallo >> sconforto per mille altre ragioni. >> >> Ci sono voluti 12 mesi di lavoro per passare da essere nessuno, a >> essere un contributore del progetto Xz. Per un progetto così ampio è >> poco, non è tanto tempo. Il lavoro psicologico di questa >> organizzazione in questo caso è stato preponderante nella testa di >> Lasse Collin. >> >> [tre settimane]<https://git.tukaani.org/?p=xz.git;a=summary> >> >> Chi sono i responsabili? >> ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ >> >> Difficile dirlo. GitHub ha sospeso il progetto Xz bloccandone la >> pagina di riferimento, ha anche bannato Lasse Collin come responsabile >> del disastro, e questo è ancora più inaccettabile anche visto gli >> sforzi (stipendiati zero Euro) da quando esiste Xz ad oggi, e dal 29 >> marzo ad ora per offrire supporto nel mitigare i danni [documentando >> tutto]. >> >> GitHub ha anche ovviamente bannato l'account di JiaT75 che ha >> fisicamente firmato gli aggiornamenti malevoli del programma, >> certo. Ma questo account non esiste, è stato creato ad hoc solo per >> questa lunghissima operazione, come lui ne possono esistere mille in >> giro. >> >> Sottolineo l'aggressività della campagna: Jia Tan ha cercato di far >> integrare la sua modifica vulnerabile anche su progetti terzi come >> 1Password (gestore di password largamente utilizzato), su Ubuntu e su >> Fedora. Progetti enormi che coinvolgerebbero una marea di utenti in >> tutto il mondo. >> >> Fortunatamente l'operazione è stata interrotta, ma la responsabilità >> in cose così grandi e impattanti (per me) è una sola: un gruppo >> sponsorizzato (anche finanziariamente) da uno Stato. Alcuni indizi >> portano alla Cina (o comunque all'oriente) per eventuali dettagli di >> orari di operatività e lingua parlata dagli utenti coinvolti, ma è >> difficile dirlo con certezza. >> >> Sicuramente si può dire che dietro ci sia una *organizzazione >> criminale dalle grosse capacità economiche*: ne sono state spese più >> dal 2021 ad oggi nella conduzione di questa campagna mirata >> all'installazione della backdoor, che in tutta la vita del progetto Xz >> per la sua realizzazione. >> >> *Il software open source è sicuro?* Sì, lo è eccome. La comunità è il >> cuore pulsante di ogni progetto e nel mondo è pieno di persone che >> vogliono offrire supporto reale per migliorare un progetto, a volte >> nato per hobby. È quando il progetto matura e diventa di proporzioni >> ciclopiche che deve arrivare il vero supporto da parte della >> comunità. Non si lascia uno sviluppatore da solo in balia del mondo, >> mentre tutti /fanno i soldi/ con la sua libreria. Non si lascia mai >> che un progetto abbia una persona da sola che pubblichi delle >> modifiche al codice, senza che altri occhi le abbiano viste e >> riviste. >> >> [documentando tutto]<https://tukaani.org/xz-backdoor/> >> >> --8<---------------cut here---------------end--------------->8--- >> >> Se avete compreso la pericolosità di questa _classe_ di backdoors >> (spiegherò nella prossima parte /quale/ classe), vi lascio immaginare >> cosa potrebbe succedere se con un sistema _analogo_ qualcuno riuscisse a >> impiantare una backdoor del genere in una libreria usata dal sistema >> operativo _proprietario_ della Intel Management Engine... o /qualsiasi/ >> sistema di out-of-band management (che è sostanzialmente un sistema >> operativo "embedded") con accesso via LAN: >> >> https://en.wikipedia.org/wiki/Out-of-band_management >> >> Intuite la portata della falla /sistemistica/ di sicurezza? :-O >> >> Fine della prima parte. >> >> Saluti, 380° >> >> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > ------------------------------------------------------------------------ > > lo straniero non parla e non capisce la nostra lingua, > che non è più nostra, perché la nostra vera lingua > diventa la traduzione, lo scambio > luca ferrieri, dalla public library all’open library > > ------------------------------------------------------------------------ > Maurizio Lana > Università del Piemonte Orientale > Dipartimento di Studi Umanistici > Piazza Roma 36 - 13100 Vercelli > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa -- Italo Vignoli - italo(a)vignoli.org mobile/signal +39.348.5653829 GPG Key ID - 0xAAB8D5C0 DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0

April 11, 2024

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

by maurizio lana

Marco Calamari in Cassandra ne ha parlato qualche giorno fa. "dignitosa coscienza e netta", lui non lo ha detto qui. Maurizio Il 11/04/24 18:25, 380° ha scritto: > Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" > non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, > iscrivetevi, se non lo siete già, alla newsletter di sicurezza della > distribuzione che state utilizzando (o rivolgetevi a un professionista). > > Buongiorno, > > per diversi giorni il mio alter ego si è occupato con una certa > _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta > scemando e può lavorare con più calma alle misure per mitigare questi > rischi... e lasciarmi scrivere qui in merito. > > Qualcuno in lista almeno ne avrà sentito palare ma forse la maggior > parte ancora non sa che il 29 Marzo 2024 è stato scoperto il peggior > supply chain attack ad oggi conosciuto. > > La vulnerabilità è tecnicamente conosciuta come CVE-2024-3094 e il NIST > gli assegna un punteggio di 10 (su 10), ma potrebbe benissimo essere 10 > cum laude:https://nvd.nist.gov/vuln/detail/CVE-2024-3094 > > I dettagli tecnici e _sistemistici_ sono relativamente (poco) complessi > e NON trascurabili per poter avere una chiara e precisa comprensione del > /modus vivendi/ ma soprattutto del /modus operandi/ che ha reso > possibile questo attacco... "nucleare". > > In merito si stanno scrivendo fiumi di parole, molte delle quali a > sproposito, anche da parte di "esperti del settore", come purtroppo > accade quando si tratta di "cose complesse" (non complicate!) di > informatica ;-(. > > In questa prima parte, come /introduzione/ alla questione vi consiglio > un articolo che ritengo meritevole. > > Prima però voglio sottolineare una opportuna quanto agghiacciante > considerazione di Bruce Schneier: > > https://www.schneier.com/blog/archives/2024/04/xz-utils-backdoor.html > > --8<---------------cut here---------------start------------->8--- > > Given how lucky we were to detect this one, I believe this kind of > operation has been successful in the past. > > --8<---------------cut here---------------end--------------->8--- > > e una totalmente inopportuna e altrettanto superficiale: > > --8<---------------cut here---------------start------------->8--- > > We simply have to stop building our critical national infrastructure on > top of random software libraries managed by lone unpaid distracted—or > worse—individuals. > > --8<---------------cut here---------------end--------------->8--- > > Ecco finalmente l'articolo introduttivo: > > https://www.insicurezzadigitale.com/backdoor-su-xz-il-problema-e-molto-piu-… > > «Backdoor su Xz: il problema è molto più grande, non è l'open source e > non si risolve con un aggiornamento. Una storia incredibile» > > Dario Fadda, 2024-04-11 > > --8<---------------cut here---------------start------------->8--- > > Mondo Linux in allarme da alcuni giorni, grande eco per la > vulnerabilità rilevata su Xz il 29 marzo appena passato. Una backdoor > installata sul codice open source della libreria largamente utilizzata > per la compressione di dati che utilizza l'algoritmo [lzma], che > *permette di eseguire codice da remoto su un server SSH* senza averne > l'autenticazione. > > Questi sono i fatti, ma il contenuto di questo articolo vuole > rispondere ad altre domande che sorgono naturalmente: come fa una > utility di compressione ad agire su SSH? Chi ha installato questa > backdoor e come ci è riuscito? > > Proviamo a vederci chiaro, ma di sicuro premetto che le favolette > dell'instabilità di un progetto open source e dell'hacker annoiato > nella propria stanza, non reggono. > > [lzma]<https://it.wikipedia.org/wiki/Algoritmo_Lempel-Ziv-Markov> > > Come funziona la backdoor su Xz? > ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ > > Non mi dilungherò in analisi dettagliate e tecniche sul funzionamento > di questa backdoor, già ampiamente dibattute ([qui] e [qui]), ma > giusto due righe per chiarirne il concetto base. > > Vista l'efficienza della libreria Xz, è da sempre utilizzata da molti > altri software che necessitano di effettuare compressione dati > (soprattutto nella gestione dei loro pacchetti). Tra gli utilizzatori > c'è pure OpenSSH, il software più utilizzato per effettuare > connessioni sicure tra client e server (gestire da remoto la shell, > quindi la completa amministrazione, di un computer disposto altrove) > via SSH. Il pacchetto OpenSSH non ha però la diretta dipendenza della > libreria Xz. Qui dobbiamo prestare attenzione a questo passaggio, > perché è il primo punto di complicazione di *come è stato congegnato > l'atterraggio verso SSH* /senza farsi beccare/: OpenSSH ha una > funzionalità di notifica sui sistemi operativi che utilizzano > *SystemD* che è governata da una libreria “libsystemd” che a sua volta > utilizza una seconda libreria che si chiama “liblzma” che è parte del > progetto Xz! Un bel giro, per iniettare del codice malevolo ed > arrivare a destinazione, sicuramente niente di /fatto in casa/. > > [qui] > <https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27> > > [qui]<https://gynvael.coldwind.pl/?lang=en&id=782> > > Come è stato possibile? > ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ > > La backdoor Xz è stata la parte finale di una campagna durata due anni > di attività, *si tratta di operazioni di human intelligence* molto > elaborate e che richiedono tempo e persone. Due anni di /lavoro/ per > avere una backdoor aperta circa tre settimane prima che venga > rilevata. C'è stato un approccio che è durato mesi prima che il > *personaggio di Jia Tan* (JiaT75 questo lo pseudonimo di chi ha > diffuso il codice malevolo all'interno del progetto Xz originale) > fosse ben posizionato per ricevere un ruolo di fiducia nel progetto, > da parte di chi segue la manutenzione diretta ( /Lasse Collin/ è > invece il suo nome). > > L'account su GitHub di *Jia Tan viene registrato nel 2021*. Non > opererà però subito su Xz, ma inizia scrivendo un commit per un altro > pacchetto open source “libarchive”. Con questo commit aggiunge una > vulnerabilità pure li che nessuno discute mai e che quindi, ad oggi > potrebbe far considerare *non sicuro pure libarchive*. > > In sintesi, Jia Tan e altri attori hanno lavorato per introdurre una > backdoor nel progetto XZ, utilizzando varie tattiche per aumentare il > controllo sul progetto e cercando di far includere la versione > compromessa in diverse distribuzioni di Linux. > > La storia > ╌╌╌╌╌╌╌╌╌ > > Subito dopo i fatti del 2021 appena descritti è un susseguirsi di > attività che portano fino ai giorni attuali. > > [...] > > La gravità > ╌╌╌╌╌╌╌╌╌╌╌ > > Da come si sono articolati gli eventi, possiamo comprendere bene la > gravità della situazione e di come l'organizzazione dietro questo > attacco, sia enormemente organizzata. Va ricordato che la versione > vulnerabile di Xz è rimasta operativa per [tre settimane] circa (dal 9 > marzo 2024), in ogni caso è plausibile che gli sforzi di questi due > anni per condurre l'operazione, mirino ai ritardi negli aggiornamenti, > prima che tutti i sistemi coinvolti (vista la diffusione dello > strumento Xz), vengano raggiunti dagli aggiornamenti necessari per > sanare il problema. > > Il modus operandi di questa cronologia di eventi, è il tipico stile di > operazione di human intelligence che punta a *sconvolgere il > bersaglio* (Lasse Collin, mantenitore del progetto), dal punto di > vista psicologico (capendo su che leve operare): ecco cosa scrive > Lasse in una mailing-list nel 2022 quando aumentavano le pressioni per > far aggiungere un altro contributore al progetto Xz. > > [immagine del messaggio: > https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html] > > Sottolinei un problema che qualcuno non è in grado di risolvere, ti > fai spalleggiare da altri utenti (finti, della tua organizzazione > malevola), e ti rendi disponibile a risolverlo. È il modo migliore per > entrare nella cerchia della fiducia, di un debole preso dallo > sconforto per mille altre ragioni. > > Ci sono voluti 12 mesi di lavoro per passare da essere nessuno, a > essere un contributore del progetto Xz. Per un progetto così ampio è > poco, non è tanto tempo. Il lavoro psicologico di questa > organizzazione in questo caso è stato preponderante nella testa di > Lasse Collin. > > [tre settimane]<https://git.tukaani.org/?p=xz.git;a=summary> > > Chi sono i responsabili? > ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ > > Difficile dirlo. GitHub ha sospeso il progetto Xz bloccandone la > pagina di riferimento, ha anche bannato Lasse Collin come responsabile > del disastro, e questo è ancora più inaccettabile anche visto gli > sforzi (stipendiati zero Euro) da quando esiste Xz ad oggi, e dal 29 > marzo ad ora per offrire supporto nel mitigare i danni [documentando > tutto]. > > GitHub ha anche ovviamente bannato l'account di JiaT75 che ha > fisicamente firmato gli aggiornamenti malevoli del programma, > certo. Ma questo account non esiste, è stato creato ad hoc solo per > questa lunghissima operazione, come lui ne possono esistere mille in > giro. > > Sottolineo l'aggressività della campagna: Jia Tan ha cercato di far > integrare la sua modifica vulnerabile anche su progetti terzi come > 1Password (gestore di password largamente utilizzato), su Ubuntu e su > Fedora. Progetti enormi che coinvolgerebbero una marea di utenti in > tutto il mondo. > > Fortunatamente l'operazione è stata interrotta, ma la responsabilità > in cose così grandi e impattanti (per me) è una sola: un gruppo > sponsorizzato (anche finanziariamente) da uno Stato. Alcuni indizi > portano alla Cina (o comunque all'oriente) per eventuali dettagli di > orari di operatività e lingua parlata dagli utenti coinvolti, ma è > difficile dirlo con certezza. > > Sicuramente si può dire che dietro ci sia una *organizzazione > criminale dalle grosse capacità economiche*: ne sono state spese più > dal 2021 ad oggi nella conduzione di questa campagna mirata > all'installazione della backdoor, che in tutta la vita del progetto Xz > per la sua realizzazione. > > *Il software open source è sicuro?* Sì, lo è eccome. La comunità è il > cuore pulsante di ogni progetto e nel mondo è pieno di persone che > vogliono offrire supporto reale per migliorare un progetto, a volte > nato per hobby. È quando il progetto matura e diventa di proporzioni > ciclopiche che deve arrivare il vero supporto da parte della > comunità. Non si lascia uno sviluppatore da solo in balia del mondo, > mentre tutti /fanno i soldi/ con la sua libreria. Non si lascia mai > che un progetto abbia una persona da sola che pubblichi delle > modifiche al codice, senza che altri occhi le abbiano viste e > riviste. > > [documentando tutto]<https://tukaani.org/xz-backdoor/> > > --8<---------------cut here---------------end--------------->8--- > > Se avete compreso la pericolosità di questa _classe_ di backdoors > (spiegherò nella prossima parte /quale/ classe), vi lascio immaginare > cosa potrebbe succedere se con un sistema _analogo_ qualcuno riuscisse a > impiantare una backdoor del genere in una libreria usata dal sistema > operativo _proprietario_ della Intel Management Engine... o /qualsiasi/ > sistema di out-of-band management (che è sostanzialmente un sistema > operativo "embedded") con accesso via LAN: > > https://en.wikipedia.org/wiki/Out-of-band_management > > Intuite la portata della falla /sistemistica/ di sicurezza? :-O > > Fine della prima parte. > > Saluti, 380° > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa ------------------------------------------------------------------------ lo straniero non parla e non capisce la nostra lingua, che non è più nostra, perché la nostra vera lingua diventa la traduzione, lo scambio luca ferrieri, dalla public library all’open library ------------------------------------------------------------------------ Maurizio Lana Università del Piemonte Orientale Dipartimento di Studi Umanistici Piazza Roma 36 - 13100 Vercelli

April 11, 2024

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

by 380°

Attenzione: NO PANIC, è molto probabile che i vostri sistemi "GNU/Linux" non siano affetti da questa backdoor in XZ (ora risolta): per saperlo, iscrivetevi, se non lo siete già, alla newsletter di sicurezza della distribuzione che state utilizzando (o rivolgetevi a un professionista). Buongiorno, per diversi giorni il mio alter ego si è occupato con una certa _apprensione_ di questa vicenda, ora per fortuna l'apprensione sta scemando e può lavorare con più calma alle misure per mitigare questi rischi... e lasciarmi scrivere qui in merito. Qualcuno in lista almeno ne avrà sentito palare ma forse la maggior parte ancora non sa che il 29 Marzo 2024 è stato scoperto il peggior supply chain attack ad oggi conosciuto. La vulnerabilità è tecnicamente conosciuta come CVE-2024-3094 e il NIST gli assegna un punteggio di 10 (su 10), ma potrebbe benissimo essere 10 cum laude: https://nvd.nist.gov/vuln/detail/CVE-2024-3094 I dettagli tecnici e _sistemistici_ sono relativamente (poco) complessi e NON trascurabili per poter avere una chiara e precisa comprensione del /modus vivendi/ ma soprattutto del /modus operandi/ che ha reso possibile questo attacco... "nucleare". In merito si stanno scrivendo fiumi di parole, molte delle quali a sproposito, anche da parte di "esperti del settore", come purtroppo accade quando si tratta di "cose complesse" (non complicate!) di informatica ;-(. In questa prima parte, come /introduzione/ alla questione vi consiglio un articolo che ritengo meritevole. Prima però voglio sottolineare una opportuna quanto agghiacciante considerazione di Bruce Schneier: https://www.schneier.com/blog/archives/2024/04/xz-utils-backdoor.html --8<---------------cut here---------------start------------->8--- Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. --8<---------------cut here---------------end--------------->8--- e una totalmente inopportuna e altrettanto superficiale: --8<---------------cut here---------------start------------->8--- We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals. --8<---------------cut here---------------end--------------->8--- Ecco finalmente l'articolo introduttivo: https://www.insicurezzadigitale.com/backdoor-su-xz-il-problema-e-molto-piu-… «Backdoor su Xz: il problema è molto più grande, non è l'open source e non si risolve con un aggiornamento. Una storia incredibile» Dario Fadda, 2024-04-11 --8<---------------cut here---------------start------------->8--- Mondo Linux in allarme da alcuni giorni, grande eco per la vulnerabilità rilevata su Xz il 29 marzo appena passato. Una backdoor installata sul codice open source della libreria largamente utilizzata per la compressione di dati che utilizza l'algoritmo [lzma], che *permette di eseguire codice da remoto su un server SSH* senza averne l'autenticazione. Questi sono i fatti, ma il contenuto di questo articolo vuole rispondere ad altre domande che sorgono naturalmente: come fa una utility di compressione ad agire su SSH? Chi ha installato questa backdoor e come ci è riuscito? Proviamo a vederci chiaro, ma di sicuro premetto che le favolette dell'instabilità di un progetto open source e dell'hacker annoiato nella propria stanza, non reggono. [lzma] <https://it.wikipedia.org/wiki/Algoritmo_Lempel-Ziv-Markov> Come funziona la backdoor su Xz? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Non mi dilungherò in analisi dettagliate e tecniche sul funzionamento di questa backdoor, già ampiamente dibattute ([qui] e [qui]), ma giusto due righe per chiarirne il concetto base. Vista l'efficienza della libreria Xz, è da sempre utilizzata da molti altri software che necessitano di effettuare compressione dati (soprattutto nella gestione dei loro pacchetti). Tra gli utilizzatori c'è pure OpenSSH, il software più utilizzato per effettuare connessioni sicure tra client e server (gestire da remoto la shell, quindi la completa amministrazione, di un computer disposto altrove) via SSH. Il pacchetto OpenSSH non ha però la diretta dipendenza della libreria Xz. Qui dobbiamo prestare attenzione a questo passaggio, perché è il primo punto di complicazione di *come è stato congegnato l'atterraggio verso SSH* /senza farsi beccare/: OpenSSH ha una funzionalità di notifica sui sistemi operativi che utilizzano *SystemD* che è governata da una libreria “libsystemd” che a sua volta utilizza una seconda libreria che si chiama “liblzma” che è parte del progetto Xz! Un bel giro, per iniettare del codice malevolo ed arrivare a destinazione, sicuramente niente di /fatto in casa/. [qui] <https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27> [qui] <https://gynvael.coldwind.pl/?lang=en&id=782> Come è stato possibile? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ La backdoor Xz è stata la parte finale di una campagna durata due anni di attività, *si tratta di operazioni di human intelligence* molto elaborate e che richiedono tempo e persone. Due anni di /lavoro/ per avere una backdoor aperta circa tre settimane prima che venga rilevata. C'è stato un approccio che è durato mesi prima che il *personaggio di Jia Tan* (JiaT75 questo lo pseudonimo di chi ha diffuso il codice malevolo all'interno del progetto Xz originale) fosse ben posizionato per ricevere un ruolo di fiducia nel progetto, da parte di chi segue la manutenzione diretta ( /Lasse Collin/ è invece il suo nome). L'account su GitHub di *Jia Tan viene registrato nel 2021*. Non opererà però subito su Xz, ma inizia scrivendo un commit per un altro pacchetto open source “libarchive”. Con questo commit aggiunge una vulnerabilità pure li che nessuno discute mai e che quindi, ad oggi potrebbe far considerare *non sicuro pure libarchive*. In sintesi, Jia Tan e altri attori hanno lavorato per introdurre una backdoor nel progetto XZ, utilizzando varie tattiche per aumentare il controllo sul progetto e cercando di far includere la versione compromessa in diverse distribuzioni di Linux. La storia ╌╌╌╌╌╌╌╌╌ Subito dopo i fatti del 2021 appena descritti è un susseguirsi di attività che portano fino ai giorni attuali. [...] La gravità ╌╌╌╌╌╌╌╌╌╌╌ Da come si sono articolati gli eventi, possiamo comprendere bene la gravità della situazione e di come l'organizzazione dietro questo attacco, sia enormemente organizzata. Va ricordato che la versione vulnerabile di Xz è rimasta operativa per [tre settimane] circa (dal 9 marzo 2024), in ogni caso è plausibile che gli sforzi di questi due anni per condurre l'operazione, mirino ai ritardi negli aggiornamenti, prima che tutti i sistemi coinvolti (vista la diffusione dello strumento Xz), vengano raggiunti dagli aggiornamenti necessari per sanare il problema. Il modus operandi di questa cronologia di eventi, è il tipico stile di operazione di human intelligence che punta a *sconvolgere il bersaglio* (Lasse Collin, mantenitore del progetto), dal punto di vista psicologico (capendo su che leve operare): ecco cosa scrive Lasse in una mailing-list nel 2022 quando aumentavano le pressioni per far aggiungere un altro contributore al progetto Xz. [immagine del messaggio: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html] Sottolinei un problema che qualcuno non è in grado di risolvere, ti fai spalleggiare da altri utenti (finti, della tua organizzazione malevola), e ti rendi disponibile a risolverlo. È il modo migliore per entrare nella cerchia della fiducia, di un debole preso dallo sconforto per mille altre ragioni. Ci sono voluti 12 mesi di lavoro per passare da essere nessuno, a essere un contributore del progetto Xz. Per un progetto così ampio è poco, non è tanto tempo. Il lavoro psicologico di questa organizzazione in questo caso è stato preponderante nella testa di Lasse Collin. [tre settimane] <https://git.tukaani.org/?p=xz.git;a=summary> Chi sono i responsabili? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Difficile dirlo. GitHub ha sospeso il progetto Xz bloccandone la pagina di riferimento, ha anche bannato Lasse Collin come responsabile del disastro, e questo è ancora più inaccettabile anche visto gli sforzi (stipendiati zero Euro) da quando esiste Xz ad oggi, e dal 29 marzo ad ora per offrire supporto nel mitigare i danni [documentando tutto]. GitHub ha anche ovviamente bannato l'account di JiaT75 che ha fisicamente firmato gli aggiornamenti malevoli del programma, certo. Ma questo account non esiste, è stato creato ad hoc solo per questa lunghissima operazione, come lui ne possono esistere mille in giro. Sottolineo l'aggressività della campagna: Jia Tan ha cercato di far integrare la sua modifica vulnerabile anche su progetti terzi come 1Password (gestore di password largamente utilizzato), su Ubuntu e su Fedora. Progetti enormi che coinvolgerebbero una marea di utenti in tutto il mondo. Fortunatamente l'operazione è stata interrotta, ma la responsabilità in cose così grandi e impattanti (per me) è una sola: un gruppo sponsorizzato (anche finanziariamente) da uno Stato. Alcuni indizi portano alla Cina (o comunque all'oriente) per eventuali dettagli di orari di operatività e lingua parlata dagli utenti coinvolti, ma è difficile dirlo con certezza. Sicuramente si può dire che dietro ci sia una *organizzazione criminale dalle grosse capacità economiche*: ne sono state spese più dal 2021 ad oggi nella conduzione di questa campagna mirata all'installazione della backdoor, che in tutta la vita del progetto Xz per la sua realizzazione. *Il software open source è sicuro?* Sì, lo è eccome. La comunità è il cuore pulsante di ogni progetto e nel mondo è pieno di persone che vogliono offrire supporto reale per migliorare un progetto, a volte nato per hobby. È quando il progetto matura e diventa di proporzioni ciclopiche che deve arrivare il vero supporto da parte della comunità. Non si lascia uno sviluppatore da solo in balia del mondo, mentre tutti /fanno i soldi/ con la sua libreria. Non si lascia mai che un progetto abbia una persona da sola che pubblichi delle modifiche al codice, senza che altri occhi le abbiano viste e riviste. [documentando tutto] <https://tukaani.org/xz-backdoor/> --8<---------------cut here---------------end--------------->8--- Se avete compreso la pericolosità di questa _classe_ di backdoors (spiegherò nella prossima parte /quale/ classe), vi lascio immaginare cosa potrebbe succedere se con un sistema _analogo_ qualcuno riuscisse a impiantare una backdoor del genere in una libreria usata dal sistema operativo _proprietario_ della Intel Management Engine... o /qualsiasi/ sistema di out-of-band management (che è sostanzialmente un sistema operativo "embedded") con accesso via LAN: https://en.wikipedia.org/wiki/Out-of-band_management Intuite la portata della falla /sistemistica/ di sicurezza? :-O Fine della prima parte. Saluti, 380° -- 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 11, 2024

Re: [nexa] [CDT:L3] The (Epistemological, n.d.r.) Enunciation Apocalypse (I said order lunch)

by Andrea Trentini

e soprattutto... "don't feed the plants!" (cit.) (i.e.: "don't link your missile launch system to a not-controlled-by-yourself cloud-based IoT system!") -- Andrea Trentini ⠠⠵ http://atrent.it public key ID: 0xA7A91E3B Dip.to di Informatica Università degli Studi di Milano

April 11, 2024

[OT ?] Re: biopotere e bossware

by 380°

Buongiorno, sì, di nuovo quella storia, di nuovo in questa lista, dove non se ne dovrebbe discutere; dovrei autocensurarmi... A mia _parziale_ discolpa vi GIURO che è l'ultima volta (ho già spergiurato?!?) che faccio riferimenti a "quella storia", non perché voglio avere /io/ l'ultima parola, semplicemente perché /io/ non ne farò mai più parola. 380° <g380(a)biscuolo.net> writes: > Carlo Blengino <blengino(a)penalistiassociati.it> writes: [...] >> introdusse l'art. 495 ter del Codice Penale che vi trascrivo: >> >> *(Fraudolente alterazioni per impedire l'identificazione o l'accertamento >> di qualità personali). - Chiunque, al fine di impedire la propria o altrui >> identificazione, altera parti del proprio o dell'altrui corpo utili per >> consentire l'accertamento di identità o di altre qualità personali, è >> punito con la reclusione da uno a sei anni.Il fatto è aggravato se commesso >> nell'esercizio di una professione sanitaria"* > > I richiami "edotti" ai temi sulla biopolitica di Foucault (et al) [1] o > "popolani" a temi fantascientifici (?!?), compreso l'intervento di > trapianto del bulbo oculare nel film "Minority Report (2002)" [2], si > sprecano; se ne possono trovare senza dubbio altre dozzine, sia "edotti" > che "popolani". > >> Ricordo anche che nell'AI ACT, "border control, immigration or asylum >> authorities" hanno ampi margini di eccezione sulle pratiche vietate. > > C'è sempre un buon motivo per fare una eccezione, ovviamente è *solo* > per la nostra (bio)sicurezza! Faccio fatica a scrivere quello che sto scrivendo, perché è stata l'ultima "goccia" che ha fatto sì che dal punto di vista "civico" (civile? "di cittadino"?) il mio alter ego abbia deciso di diventare un *disertore* (in piena facoltà...). Io non sono un esperto di giurisprudenza, dicamo che sono molto ignorante (ma non per questo deficiente), quindi non ho specifici riferimenti a esempi di norme che lasciano "ampi margini di eccezione sulle pratiche vietate" alle _autorità_. ...però c'è IL "elefante nella stanza" che dimostra inequivocabilmenre come per le autorità BIOPOLITICHE (si veda Foucault et al) ci può _sempre_ essere una validissimo motivo, SCIENTIFICAMENTE provato, per applicare un'eccezione a norme di QUALSIASI livello, fino alla definizione stessa di "diritto umano", specialmente in stati di perenne - anzi _precognitiva_ - emergenza come guerre e pandemie. Qui un articolo che ripercorre (rapidamente) la recentissima storia dello stato di diritto in epoca di COVID-19: --8<---------------cut here---------------start------------->8--- Non c’è follia anti-scientifica che non sia stata sperimentata in quel periodo. In poche parole: con il pretesto di combattere un virus -potenzialmente mortale, subdolo e imprevedibile, ma curabile quasi sempre a domicilio, purché trattato ai primi sintomi- si è proceduto a smantellare lo Stato di diritto. [...] L’apice, però, è stato raggiunto tra il 2021 e il 2022, in occasione della campagna vaccinale più imponente della Storia. [...] Diritti innati trasformati in mere concessioni: a poco a poco i non vaccinati furono privati dello stipendio e/o esclusi dalla vita sociale. La civiltà umana terminò con il Green Pass, spacciato per ‘strumento che dà la garanzia di ritrovarsi tra persone non contagiose e non contagianti’ (Mario Draghi, allora Presidente del Consiglio). [...] In realtà si potrebbe anche mentire per sempre, facendola franca. Ed è ciò che accadrà con le varie commissioni post-pandemiche. Non fatevi illusioni: i danneggiati resteranno beffati e inascoltati, mentre coloro che stanno abbattendo lo Stato di diritto si ritroveranno magicamente ad occupare ruoli di maggior prestigio. [...] Il copia e incolla in serie può essere fatto anche da un computer, che magari vi sostituirà pure. --8<---------------cut here---------------end--------------->8--- Articolo completo: https://www.buongiornosuedtirol.it/2024/04/censura-e-verita-negate-il-naso-… «Censura e verità negate: il naso di Pinocchio e il segreto di Pulcinella» di Francesco Servadio, 10 Aprile 2024 >> Un disastro a cui pare impossibile rimediare. Sì è _letteralmente_ /impossibile/ rimediare. Non con queste istituzioni... mondiali. Non con questa credibilità del "mainstream"... mondiale. [...] Loving, 380° P.S.: ovviamente c'è sempre un buon motivo per dire che tutto questo non c'entra assolutamente niente con la discussione in corso nel thread, cioè che è off-topic... ed in effetti lo è, OT. -- 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 11, 2024

[CDT:L3] The (Epistemological, n.d.r.) Enunciation Apocalypse (I said order lunch)

by 380°

Buongiorno, un amico ha ricevuto "via social" (e mi ha girato via chat) una vignetta umoristica che ci è piaciuta molto, purtroppo senza il minimo riferimento all'origine. ...trovata! É del Maggio 2021, ma molto attuale: https://www.gocomics.com/nonsequitur/2021/05/24 [1] «Non Sequitur by Wiley Miller for May 24, 2021» Come corollario, ho trovato questa "notizia" del Giugno 2021 su una testata Indiana, che parte da un tweet di un importante politico indiano che rilancia una versione leggermente ritoccata della vignetta (che è quella che ho ricevuto io): https://www.ndtv.com/india-news/with-enunciation-apocalypse-sketch-tharoor-… «Shashi Tharoor's Word Of The Day For "Those Who Make Snarky Remarks..."» --8<---------------cut here---------------start------------->8--- In a tweet, Shashi Tharoor shared a cartoon, serving as a reminder why "enunciation" or pronouncing words clearly is important. [...] Congress leader Shashi Tharoor, known to amuse his Twitter followers with his fabulous vocabulary, this morning gave a cheeky response to those "who issue snarky remarks daily" about his diction. This is for all those who issue snarky remarks daily about my diction — a reminder of why enunciation *is* important! pic.twitter.com/VPKPHbz8cb — Shashi Tharoor (@ShashiTharoor) June 2, 2021 [2] Titled "The Enunciation Apocalypse", the cartoon shows some military personnel inside a monitoring station with large television screens hanging from the wall. One of them gives a command to Alexa, the voice-controlled virtual assistant. Asked to order "lunch", the device misunderstands and takes it for missile "launch". --8<---------------cut here---------------end--------------->8--- Uno dei tweet di commento all'"articolo indiano" dice: --8<---------------cut here---------------start------------->8--- Its has happened to me while experimenting with NLP code. Luckily my code was not connected to nuclear missile but at times felt like system was hurling out profanity. [...] — Siddharth Savant (@siddhu92) June 2, 2021 [3] --8<---------------cut here---------------end--------------->8--- "Luckily" :-D Giusto per contestualizzare il ragionamento, si tratta di "cosine" linguistiche per le quali non sarebbe sufficiente un convegno di tre giorni sulla fonetica: https://en.wikipedia.org/wiki/Received_Pronunciation --8<---------------cut here---------------start------------->8--- The word 'received' conveys its original meaning of 'accepted' or 'approved', as in 'received wisdom'. --8<---------------cut here---------------end--------------->8--- (si veda l'intero articolo) ... *combinate* con "cosine" _sistemistiche_ per le quali non sarebbe sufficiente un convegno di tre _settimane_ sulla robotica (_molto_ più multidisciplinare di quello sulla fonetica, perché si parte dall'ingegneria elettrotecnica e si finisce con la neurofisiologia, anzi no, con la _filosofia_): https://en.wikipedia.org/wiki/Autonomous_robot --8<---------------cut here---------------start------------->8--- a robot that acts without recourse to human control. The first autonomous robots environment were known as Elmer and Elsie, which were constructed in the late 1940s by W. Grey Walter. They were the first robots in history that were programmed to "think" the way biological brains do and meant to have free will. --8<---------------cut here---------------end--------------->8--- Faccio sommessamente notare che Elmer e Elsie ("Machina speculatrix") furono costruite da un _neurobiologo_ che voleva dimostrare: --8<---------------cut here---------------start------------->8--- [...] that rich connections between a small number of brain cells could give rise to very complex behaviors - essentially that the secret of how the brain worked lay in how it was wired up [...] [...] Walter stressed the importance of using purely analogue electronics to simulate brain processes at a time when his contemporaries such as Alan Turing and John von Neumann were all turning towards a view of mental processes in terms of digital computation. --8<---------------cut here---------------end--------------->8--- (rif. https://en.wikipedia.org/wiki/William_Grey_Walter#Robots) Per favore andate voi a studiare in cosa consistevano Elmer e Elsie e in cosa consistono i robot autonomi del giorno d'oggi [4], non fatevelo raccontare da me. ...specialmente il senso dell'aggettivo "autonomo" in quel contesto, per favore. Mi fermo qui. Saluti, 380° [1] archiviata qui: https://web.archive.org/web/20210524063016/https://www.gocomics.com/nonsequ… e qui: https://archive.is/pHv3t [2] https://twitter.com/ShashiTharoor/status/1399950572170584067 [3] https://twitter.com/siddhu92/status/1399951954604789761 [4] oggi al 99,99% basati sulla visione "turinghiana" dei processi mentali in termini computazionali, perché i BEAM robot praticamente non esistono: https://en.wikipedia.org/wiki/BEAM_robotics -- 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 11, 2024

Re: [nexa] Fwd: invito a Nexa

by J.C. DE MARTIN

Scusate, lista sbagliata.... e scusate anche lo spoiler :-) jc On 11/04/24 07:17, J.C. DE MARTIN wrote: > L'8 maggio c'è Lieto, che non è spostabile, vero, Dante? > > Se è così, allora le diciamo 11 settembre, ok? > > jc > > > -------- Forwarded Message -------- > Subject: Re: invito a Nexa > Resent-From: juancarlos.demartin(a)polito.it > Date: Wed, 10 Apr 2024 22:38:04 +0200 > From: Giovanna Sissa <sissa.giovanna(a)gmail.com> > To: J.C. DE MARTIN <demartin(a)polito.it> > > > > Caro Juan Carlos, > purtroppo mercoledì 12 giugno non ce la faccio ad essere a Torino. > Parlando di secondi mercoledì del mese, potrei essere a Torino l'8 > maggio o l'11 settembre > Giovanna > > > > Il giorno mer 10 apr 2024 alle ore 17:25 J.C. DE MARTIN > <demartin(a)polito.it> ha scritto: > > Cara Giovanna, > > non posso ancora confermartelo, ma in linea di principio tu > potresti *mercoledì 12 giugno*? L’incontro sarebbe dalle 17 alle 19. > > jc > > (messaggio spedito in movimento - scusate brevità ed eventuali refusi) > >> Il giorno 5 apr 2024, alle ore 18:30, Giovanna Sissa >> <sissa.giovanna(a)gmail.com> ha scritto: >> >> >> Caro Juan Carlos, >> resto in attesa dunque che mi contattino i tuoi colleghi per un >> mercoledì di Nexa. Mi fa molto piacere e ti ringrazio dell’invito. >> A presto >> Giovanna >> >> Il giorno ven 5 apr 2024 alle 16:09 J.C. DE MARTIN >> <juancarlos.demartin(a)polito.it> ha scritto: >> >> Cara Giovanna, >> >> grazie molte per la tua disponibilità per venire al Centro >> Nexa a presentare e discutere il tuo nuovo libro, *"Le >> emissioni segrete. L'impatto ambientale dell'universo >> digitale"*, Il Mulino, marzo 2024 [1]. >> >> Idealmente ci piacerebbe averti a un "Mercoledì di Nexa", che >> si tiene il 2° mercoledì del mese dalle 17 alle 19. I >> colleghi che hanno il calendario dei prossimi incontri ti >> contatteranno per concordare con te una data che possa >> funzionare per tutti. >> >> Intanto ancora grazie e, spero, a prestissimo! >> >> juan carlos >> >> [1] >> https://www.mulino.it/isbn/9788815388636?forcedLocale=it&fbrefresh=CAN_BE_A… >> <https://www.mulino.it/isbn/9788815388636?forcedLocale=it&fbrefresh=CAN_BE_A…> >> >> >> >>

April 11, 2024

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

Jump to page: