- nexa - server-nexa.polito.it

Re: [nexa] Guida autonoma

by Guildor

No, il link per disiscriversi non sembra funzionare. > Il giorno 14 apr 2024, alle ore 09:27, Marco A. Calamari <marcoc_maillist(a)marcoc.it> ha scritto: > > > La guida autonoma è un argomento sgradito? > > E la disiscrizione fatta dall'iscritto non funziona più? > > On dom, 2024-04-14 at 06:56 +0000, Massimo Maggiore wrote: >> Anche io chiedo di essere rimosso dalla mailing list >> Grazie >> >> >> >> Inviato dal mio Galaxy >> >> >> >> -------- Messaggio originale -------- >> Da: Bruna Capparelli via nexa <nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it>> >> Data: 14/04/24 07:27 (GMT+01:00) >> A: Diego Giorio <dgiorio(a)hotmail.com <mailto:dgiorio@hotmail.com>> >> Cc: nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >> Oggetto: Re: [nexa] Guida autonoma >> >> Buongiorno, >> >> chiedo per favore di essere depennata dalla mailing. >> >> Grazie, un cordiale saluto >> >> > Il giorno 13 apr 2024, alle ore 22:42, Diego Giorio <dgiorio(a)hotmail.com <mailto:dgiorio@hotmail.com>> ha scritto: >> > >> > >> > Credo che questo episodio possa interessare ai nexiani >> > >> > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.macit… <https://www.macitynet.it/tesla-porta-ospedale-proprietario-infarto/> >> > >> > Buona domenica >> > >> > D. >> > _______________________________________________ >> > nexa mailing list >> > nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >> > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-ne… <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa> >> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-ne… <https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 14, 2024

Re: [nexa] Guida autonoma

by Marco A. Calamari

La guida autonoma è un argomento sgradito? E la disiscrizione fatta dall'iscritto non funziona più? On dom, 2024-04-14 at 06:56 +0000, Massimo Maggiore wrote: > Anche io chiedo di essere rimosso dalla mailing list > Grazie > > > > Inviato dal mio Galaxy > > > > -------- Messaggio originale -------- > Da: Bruna Capparelli via nexa <nexa(a)server-nexa.polito.it> > Data: 14/04/24 07:27 (GMT+01:00) > A: Diego Giorio <dgiorio(a)hotmail.com> > Cc: nexa(a)server-nexa.polito.it > Oggetto: Re: [nexa] Guida autonoma > > Buongiorno, > > chiedo per favore di essere depennata dalla mailing. > > Grazie, un cordiale saluto > > > Il giorno 13 apr 2024, alle ore 22:42, Diego Giorio <dgiorio(a)hotmail.com> ha > scritto: > > > > > > Credo che questo episodio possa interessare ai nexiani > > > > > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.macit… > > > > Buona domenica > > > > D. > > _______________________________________________ > > nexa mailing list > > nexa(a)server-nexa.polito.it > > > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-ne… > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-ne… > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 14, 2024

Re: [nexa] Guida autonoma

by Massimo Maggiore

Anche io chiedo di essere rimosso dalla mailing list Grazie Inviato dal mio Galaxy -------- Messaggio originale -------- Da: Bruna Capparelli via nexa <nexa(a)server-nexa.polito.it> Data: 14/04/24 07:27 (GMT+01:00) A: Diego Giorio <dgiorio(a)hotmail.com> Cc: nexa(a)server-nexa.polito.it Oggetto: Re: [nexa] Guida autonoma Buongiorno, chiedo per favore di essere depennata dalla mailing. Grazie, un cordiale saluto > Il giorno 13 apr 2024, alle ore 22:42, Diego Giorio <dgiorio(a)hotmail.com> ha scritto: > > > Credo che questo episodio possa interessare ai nexiani > > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.macit…<https://www.macitynet.it/tesla-porta-ospedale-proprietario-infarto/> > > Buona domenica > > D. > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-ne…<https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa> _______________________________________________ nexa mailing list nexa(a)server-nexa.polito.it https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver-ne…<https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa>

April 14, 2024

Re: [nexa] Guida autonoma

by Bruna Capparelli

Buongiorno, chiedo per favore di essere depennata dalla mailing. Grazie, un cordiale saluto > Il giorno 13 apr 2024, alle ore 22:42, Diego Giorio <dgiorio(a)hotmail.com> ha scritto: > > > Credo che questo episodio possa interessare ai nexiani > > https://www.macitynet.it/tesla-porta-ospedale-proprietario-infarto/ > > Buona domenica > > D. > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 14, 2024

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