April 2021 - nexa - server-nexa.polito.it

Google Workspace for Education

by Giuseppe Attardi

Fine dell’era dei servizi gratuiti di Google illimitati a scuole e università. Spazio disco massimo di 100TB per istituto. https://www.blog.google/outreach-initiatives/education/google-workspace-for… — Beppe

April 23, 2021

Backdoor Found in Codecov Bash Uploader (Supply Chain Attack)

by Giovanni Biscuolo

Buongiorno, https://www.schneier.com/blog/archives/2021/04/backdoor-found-in-codecov-ba… --8<---------------cut here---------------start------------->8--- Developers have discovered a backdoor in the Codecov bash uploader. It’s been there for four months. We don’t know who put it there. Codecov said the breach allowed the attackers to export information stored in its users’ continuous integration (CI) environments. This information was then sent to a third-party server outside of Codecov’s infrastructure,” the company warned. Codecov’s Bash Uploader is also used in several uploaders — Codecov-actions uploader for Github, the Codecov CircleCl Orb, and the Codecov Bitrise Step — and the company says these uploaders were also impacted by the breach. According to Codecov, the altered version of the Bash Uploader script could potentially affect: * Any credentials, tokens, or keys that our customers were passing through their CI runner that would be accessible when the Bash Uploader script was executed. * Any services, datastores, and application code that could be accessed with these credentials, tokens, or keys. * The git remote information (URL of the origin repository) of repositories using the Bash Uploaders to upload coverage to Codecov in CI. Add this to the long list of recent supply-chain attacks. --8<---------------cut here---------------end--------------->8--- Tragicomicamente, la pagina principale del software https://about.codecov.io/ recita proprio: --8<---------------cut here---------------start------------->8--- Ship healthier code faster with less risk. Development cycles are spinning faster than ever... With everything from doorbells to rockets running on code, it's more important than ever to ensure quality code is being delivered with every release. Code coverage is one of the most important metrics companies rely on to ship healthier code, faster, and with less risk. Codecov gives companies actionable coverage insights when and where they need them to ensure they are shipping quality code. --8<---------------cut here---------------end--------------->8--- Ma Codecov userà Codecov?!? C'è un problema di bootstrapping? B-) D'altronde cosa potrebbe andar storto quando per installare il software si deve fare: "bash <(curl -s https://codecov.io/bash)" [1] ?!? :-O D'altronde cosa potrebbe andar storto quando si usano un po' toppo allegramente le "ricette" Docker per creare gli ambienti di deployment [2]?!? --8<---------------cut here---------------start------------->8--- The actor gained access because of an error in Codecov’s Docker image creation process that allowed the actor to extract the credential required to modify our Bash Uploader script --8<---------------cut here---------------end--------------->8--- ...se l'avessi fatto io sarei già stato (metaforicamente!) esiliato in orbita attorno a Saturno :-O Saluti, Giovanni. [1] https://docs.codecov.io/docs/about-the-codecov-bash-uploader [2] https://www.securityweek.com/codecov-bash-uploader-dev-tool-compromised-sup… -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.

April 23, 2021

Trusting What? It’s time to admit we have a problem. (was Re: Divertentissimi Hack accademici... sul kernel Linux)

by Giovanni Biscuolo

Ciao Giacomo, come sempre interessanti le tue segnalazioni, grazie. Attenzione: questo mio messaggio è un po' lungo, leggetelo solo se avete tempo e voglia di approfondire cose piuttosto tecnico-ostiche e politico-controverse... ma che coinvolgono tutti. Ci sarebbero così taaaante cose da dire attorno a questa storia ma cercherò di stare sulle questioni più rilevanti. Avevo visto anche io il paper intitolato: «On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits» Ho letto per ora solo l'abstract perché non ho avuto tempo e onestamente la questione non mi sembra particolarmente nuova :-O Dovrebbe essere presentato in Maggio al 42nd IEEE Symposium on Security and Privacy (Oakland’21)... ma non so se ci arriverà considerato l'astio (forse ingiustificato) che ha prodotto. L'autore è Qiushi Wu ed è uno studente del dipartimento di computer science dell'università del Minnesota https://qiushiwu.github.io/#publications AFAIU il casino dei patch maliziosi in Linux l'hanno messo in piedi per dimostrare la loro tesi che inserire vulnerabilità nascoste/incomprese è semplice, sostenuti dal loro professore: non mi pare (ma devo approfondire) che siano riusciti a dimostrarlo visto che tutto quello che hanno ottenuto è di essere estromessi dalla community Linux, che se ne è accorta. Comunque la cosa non deve far stare per nulla tranquilli, come giustamente sottolinei tu Giacomo più avanti, anche perché non esiste solo la malizia come motivazione che può spingere qualcuno ha introdurre nel software bachi che passino il più possibile inosservati, anche solo per qualche settimana, esistono anche le minacce. La notizia mi è arrivata perché Trentini mi ha segnalato che Greg Kroah-Hartman, il maintainer del branch stable di Linux, ha dichiarato che scarterà automaticamente tutti i contributi provenienti da quella università. https://www.neowin.net/news/linux-bans-university-of-minnesota-for-sending-… O **meglio ancora* leggere direttamente le sue parole: https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ Giacomo Tesio <giacomo(a)tesio.it> writes: [...] > Le conclusioni della ricerca sono molto interessanti Prima cosa importantissima: quella ricerca ha fatto e farà rumore nell'ambiente e chi l'ha condotta deve solo essere ringraziato, anche se mi mancano ancora dettagli per capire perché le contromisure messe in atto dal progetto stesso per evitare che il codice malizioso finisse in Linux mainline stable NON abbiano funzionato, a quanto ho capito. Poi veniamo alle conclusioni ma *prima* fammi commentare le *premesse*: --8<---------------cut here---------------start------------->8--- Abstract — Open source software (OSS) has thrived since the forming of Open Source Initiative in 1998. A prominent example is the Linux kernel, which has been used by numerous major software vendors and empowering billions of devices. --8<---------------cut here---------------end--------------->8--- OK, va bene, tutto è iniziato nel 1998 grazie alla OSI come se prima ci fosse il deserto: ottimo punto di partenza per una ricerca accademica! --8<---------------cut here---------------start------------->8--- The higher availability and lower costs of OSS boost its adoption, while its openness and flexibility enable quicker innovation. --8<---------------cut here---------------end--------------->8--- Anche queste cose (quicker innovation: INNOVATION?!?) vengono presentate come "dati", boh? Giusto per capirci, il fatto che Linux (o altri software conosciutissimi) abbia avuto tutto questo grande successo NON dipende dalle sue qualità tecniche, men che meno da implementazioni innovative. --8<---------------cut here---------------start------------->8--- More importantly, the OSS development approach is believed to produce more reliable and higher-quality software since it typically has thousands of independent programmers testing and fixing bugs of the software collaboratively. --8<---------------cut here---------------end--------------->8--- Evabbè però, vogliamo davvero basare la dialettica e l'indagine socio-politica attorno al software e le sue conseguenze sociali e tecniche su queste favolette vuote ormai superate da anni?!? > e sottolineano diverse criticità notoriamente importanti dell'open > source Dai Giacomo: quando ci sono le rogne si chiama "Open Source" e quando ci sono le lodi si chiama "Software Libero"?!? :-P [...] > La criticità che NON sottolinea è: se degli studenti sono riusciti ad > introdurre scientemente vulnerabilità in Linux, chi altri c'è riuscito > senza farsi beccare prima di loro? Purtroppo il fatto che possano essere introdotte vulnerabilità, scientemente o meno, dipende da un insieme eterogeneo e complesso di condizioni, all'interno delle quali la malizia (o malafede) ha ampie possibilità di essere esercitata passando inosservata. Una delle criticità a mio avviso ancora troppo poco affrontata, sebbene ben compresa dagli addetti ai lavori, sta esattamente nel linguaggio nelle quali sono espresse tali vulnerabilità: il C (e derivati come C++). E attenzione che ho usato "espresse le vulnerabilità" e non "espresso il codice" /non a caso/. É assurdo che ancora nel 2021 possano essere introdotti, volontariamente o meno, pezzi di codice sorgente che provocano "uscite dallo spazio di memoria del processo" binario, la c.d. "memory unsafety" [1] che almeno dal 1988 è chiaramente individuata come la causa di praticamente il 90% dei bachi di sicurezza di tutto il software mai prodotto dall'umanità, proprietario o libero. Io domando: perché i programmatori devono essere costretti a verificare che il proprio codice non abbia dei bachi (anche adottando strumenti di analisi statica e tecniche analoghe, tutte costosissime) che /semplicemente/... non dovrebbero esistere perché non possono essere nemmeno espressi?!? ...o ancora peggio che patch di /altri/ non introducano simili bachi, che sia fatto apposta oppure in buona fede? --8<---------------cut here---------------start------------->8--- Google’s Project Zero has found more than 1,000 vulnerabilities, many of them memory unsafety (70 of the 86 critical vulnerabilities are memory corruption). It’s time to admit we have a problem. Memory unsafety is a scourge plaguing our industry. But because it results in thousands of vulnerabilities, instead of one flashy one, we don’t give it nearly the attention it deserves. This is, of course, entirely backwards, if we were to perform a root cause analysis on all of these bugs, we’d find the same thing over and over again. Just because it doesn’t have a name, doesn’t make it any less devastating. --8<---------------cut here---------------end--------------->8--- (https://alexgaynor.net/2017/nov/20/a-vulnerability-by-any-other-name/ by Alex Gaynor, Nov 20, 2017) Oppure, per essere decisamente politicamente scorretti: --8<---------------cut here---------------start------------->8--- In a world where programs control credit-card databases, car brakes, my personal finances, airplanes, and x-ray machines, it is criminal negligence to use a language with the flaws of C/C++. Even for games, browsers, and spreadsheets, the use of C/C++ needlessly helps inflict buggy software on the everyday user. --8<---------------cut here---------------end--------------->8--- (https://www.radford.edu/ibarland/Manifestoes/whyC++isBad.shtml Ian Barland, 25 Aprile 2019) Lo so anche io che (forse?) un kernel scritto in Lisp o Haskell - o in generale con sistemi memory safe con garbage collectors - sarebbe Troppo Lento per le esigenze di velocità supersonica contemporanee, che certe funzioni devono per forza essere scritte in un linguaggio di programmazione a basso livello per essere veloci... però possibile che non si possa fare di meglio?!? Possibile che non ci sia l'opportunintà di contribuire al software /anche solo/ per la parte in cui si può fare tutto in modo "memory safe"?... e tutto il resto "memory unsafe" sottoposto a scrupolosissime (e costose) verifiche prima di essere rilasciato *e* modificato? Pare che la soluzione a tutti i mali del C debba essere Rust, "come il C ma memory safe": evviva! ...peccato che *siccome* per scrivere codice in kernel space (codice con permessi illimitati di accesso a qualsiasi locazione di memoria) c'è bisogno anche di scrivere "a basso livello", andrà a finire che praticamente tutti useranno "unsafe Rust" [2] per scrivere quel codice. Dice: «You can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.”»... ecco, appunto, il problema è /esattamente/ quello: vi sfido a trovarmi sulla faccia della terra un programmatore esperto (in qualsiasi linguaggio) che sia disposto ad ammettere "actually I really don't know what I'm doing". :-O Giacomo giustamente tu proponi di risolvere la questione scrivendo sistemi semplici da comprendere - tipo Jehanne http://jehanne.io/pages/overview.html - e quindi meno soggetti a richi di cadere sotto il peso della loro complessità. Concordo con te, l'approccio KISS (per ciascun singolo programma o funzione) dovrebbe essere il mantra di ogni persona di buon senso, ma *purtroppo* non sta funzionando così... e comunque i sistemi, anche i sistemi operativi, sono complessi e la complessità si può tenere sotto controllo solo e soltanto se c'è un intero sovra-sistema in grado di gestirla tale complessità. Storicamente sono già stati scritti diversi kernel tecnicamente più avanzati di Linux ma per via di un sovra-sistema che non è in grado di gestire questo ordine di complessità, lavorare su quelli non porta... il becco di un quattrino, l'industria ha bisogno di continuare rappezzare Linux (e il browser, Internet, ecc.). [...] Ma sai Giacomo qual'è l'ironia di tutto questo, l'ironia della vulnerabilità del software, anche quello Open Source... i nostri kernel e sistemi operativi, Linux compreso, nel 90% dei casi "girano" come macchine virtuali all'interno di un host derivato da MINIX3 del quale non non abbiamo il benché minimo controllo; quell'host ha accesso illimitato alla memoria RAM, al disco e alla rete senza che Linux manco se ne accorga e dispone di un comodo server web accessibile chissà come e con chissà quali credenziali. Di che sicurezza stiamo parlando? ;-) Trusting What? :-O Ciao, Giovanni. [1] https://en.wikipedia.org/wiki/Memory_safety#History [2] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.

April 23, 2021

Re: [nexa] Oggi, 22 Aprile - 20:30, LinuxTrent riprende oggi gli incontri online. Rispettando la riservatezza le persone

by Roberto Resoli

Il 22 aprile 2021 09:19:32 CEST, Roberto Resoli <roberto(a)resolutions.it> ha scritto: >Salve a tutti, ... >Per chi vuole, siamo in diretta oggi, alle 20:30. Marco Agostini >parlerà >delle sue esperienze con FreePBX, una interfaccia web per il server >VOIP >Asterisk: > >https://www.linuxtrent.it/finalmente-uninterfaccia-per-asterisk-con-i-fiocc… Marco ha voluto rendere pubblica la sua presentazione, lo ringraziamo di cuore. https://video.linuxtrent.it Permettetemi una nota personale: è impressionante quello che riesce a fare una persona motivata, anche nel contesto di un piccolo comune, utilizzando gli stumenti messi a disposizione dalla conoscenza collettiva. >a seguire, altri incontri (anche di argomento molto più generale e >disparato). > >ciao, >rob > >[1] https://joinpeertube.org/ >[2] https://github.com/JohnXLivingston/peertube-plugin-livechat >_______________________________________________ >nexa mailing list >nexa(a)server-nexa.polito.it >https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 23, 2021

Mala innovazione: se bisogna fermarsi per salvare l’umano

by Antonio Iacono

Quello in oggetto è il titolo di un articolo di Alessandro Longo di un paio di giorni fa [1] che termina con: "A volte la cosiddetta innovazione va fermata. A volte, almeno, dobbiamo (sof)fermarci noi (per un po’): per riflettere sulla bontà di quell’innovazione e di come integrarla nell’umano, rendendola umana. Come dicono sempre più esperti di intelligenza artificiale e come suggerisce lo stesso Regolamento UE. Vanno tutelati così gli interessi di fruitori di quella tecnologia, ma anche dei lavoratori, sui cui diritti non possiamo permetterci passi indietro. Appunto: un’innovazione che fa fare passi indietro alla società non è un’innovazione; ma ha una funzione regressiva." Avevo scritto cose simili in questa lista un paio di mesi fa, sono quindi d'accordo con quanto detto da Longo. Una piccola chiosa storica. Agli inizi degli anni Sessanta, a guidare l'ARPA c'era Jack Ruina [2]. Anni dopo, ad una intervista, a chi gli chiese cosa si aspettassero i militari dall'ARPA e dall'intelligenza artificiale, rispose: "L'idea che avevano era di immettere in un potente calcolatore informazioni qualitative del tipo: 'Il comandante dell'aviazione ha bevuto due Martini' oppure ' Khrushchev non legge la Pravda il lunedì' e il computer avrebbe recitato la parte di Sherlock Holmes, e ne avrebbe concluso che i russi stavano costruendo un missile MX-72, o qualcosa del genere." Sia Ruina che Joseph Licklider [3] cercarono di mettere un freno a questo "modo idiota di procedere" [parole loro]. Poco tempo dopo un altro "pioniere dell'informatica moderna", tale Douglas Engelbart [4] (se usiamo il 'mouse' è anche grazie a lui) faticò a far passare l'idea di "intelligenza aumentata", il suo "Augmenting Human Intellect" [5] anticipava il computer e internet di qualche decennio. Engelbart capì subito che i fautori dell'intelligenza artificiale erano i suoi nemici filosofici. La loro "missione" era rimpiazzare gli esseri umani con della macchine, mentre la sua visione consisteva nell'estendere le capacità dell'uomo. Ruina, Licklider, Engelbart, e poi Stallman e molti altri, gente che non si limitava a seguire il "mainstream". Sessant'anni dopo le cose non sono cambiate di molto Al posto dei tecnici in camice bianco che inseriscono schede perforate negli enormi mainframe per "individuare modelli comportamentali fra gli alti ufficiali sovietici", ci siamo noi che, volontariamente e gratuitamente, immettiamo continuamente dati nella "megamacchina" che è la rete. E dall'altra parte c'è ancora chi, per interesse economico, politico o militare, prova ancora a "individuare modelli comportamentali", stavolta non degli odiati russi ma di tutti noi. Se c'è un compito a cui l'università dovrebbe adempiere è quello di formare degli "Engelbart" dotati di spirito critico e la forza e il coraggio di sapere andare controcorrente (anche se questo dovesse significare abbandonare il "proprio settore" per dedicarsi ad altri "campi di ricerca"). Antonio [1] https://www.agendadigitale.eu/cultura-digitale/se-linnovazione-ci-fa-male-d… [2] https://en.wikipedia.org/wiki/Jack_Ruina [3] https://it.wikipedia.org/wiki/Joseph_Licklider [4] https://it.wikipedia.org/wiki/Douglas_Engelbart [5] https://www.dougengelbart.org/content/view/138

April 23, 2021

Re: [nexa] How I Fought To Graduate Without Using Nonfree Software

by Andrea Trentini

On 23/04/2021 00:23, Giovanni Biscuolo wrote: > [...] > [1] io tanto tempo fa ci ho messo il naso in università /ma/ > "Reflections on Trusting Trust" l'ho "scoperto" da solo anni dopo... c'è > la probabilità quindi che anche oggi si laureino in informatica persone > che non hanno idea di cosa sia. con p = ~1 -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano

April 23, 2021

Re: [nexa] How I Fought To Graduate Without Using Nonfree Software

by Giovanni Biscuolo

Antonio Iacono <antiac(a)gmail.com> writes: [...] > Fosse solo il software libero il problema dell'università italiana :( condivido la tua tristezza per certe storture, Antonio, però non sottovaluterei il fatto che, dal mio parziale punto di osservazione, i professori universitari mostrano generalmente scarsa sensibilità verso gli aspetti etici e politici dell'informatica e dello sviluppo del software, a partire dalla questione del "Trusting Trust" [1] in su. La tecnica (e i tecnici) è fatta in un certo modo mica perché è una legge della natura, neh :-O [...] Ciao, Giovanni. [1] io tanto tempo fa ci ho messo il naso in università /ma/ "Reflections on Trusting Trust" l'ho "scoperto" da solo anni dopo... c'è la probabilità quindi che anche oggi si laureino in informatica persone che non hanno idea di cosa sia. -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.

April 22, 2021

Re: [nexa] How I Fought To Graduate Without Using Nonfree Software

by Giovanni Biscuolo

Ciao Andrea, Andrea Trentini <andrea.trentini(a)unimi.it> writes: > On 22/04/2021 18:12, Giovanni Biscuolo wrote: >> ... >> Professori di informatica cosa rispondete a questa constatazione: «As I >> mentioned earlier, despite being highly knowledgeable computer >> scientists and experienced in informatics, many academics demonstrated a >> generally poor understanding of the politics and ethics around >> software.» ? > > non posso che concordare con lui, da noi in dipartimento la > sensibilità verso questi temi è abbastanza bassa (se ci sono colleghi > in lista mi smentiscano, sarò ben contento!) grazie per esserti espresso anche pubblicamente, diciamo che nei miei trascorsi anni di militanza in alcuni gruppi di advocacy, fuori dall'università, tu sei uno dei pochi professori di informatica sensibili al tema; anche io vorrei tanto essere smentito > tanto che io ormai ho quasi smesso di lottare internamente per > l'adozione del sw libero (evitando cmq per quanto possibile ogni sw > proprietario e sensibilizzando in ogni caso gli studenti sul tema) > dedicandomi al mondo esterno (cfr. libro CDT) dove magari qualche > soddisfazione in più si ottiene... peccato perché ci sarebbe tanto bisogno di una spinta che dall'università di propaghi verso l'esterno [...] Ciao, Giovanni P.S.: è stato Andrea a segnalarmi l'articolo, ma è timido :-D -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.

April 22, 2021

Divertentissimi Hack accademici... sul kernel Linux

by Giacomo Tesio

Ciao a tutti, vi invito alla lettura di questo thread fresco fresco di questi giorni su una delle mailing list di sviluppo del kernel Linux (NFS) https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/ > Those commits are part of the following research: > https://github.com/QiushiWu/qiushiwu.github.io/raw/main/papers/OpenSourceIn… > > They introduce kernel bugs on purpose. Yesterday, I took a look on 4 > accepted patches from Aditya and 3 of them added various severity > security "holes". Le conclusioni della ricerca sono molto interessanti e sottolineano diverse criticità notoriamente importanti dell'open source > This paper presented hypocrite commits, which can be > abused to stealthily introduce vulnerabilities in OSS. Three > fundamental reasons enable hypocrite commits: the openness > of OSS, which allows anyone including malicious committers > to submit patches; the limited resources of OSS maintaining; > and the complexity of OSS programs, which results in the > manual review and existing tools failing to effectively identify > introduced vulnerabilities. We then systematically characterized > immature vulnerabilities and studied how a malicious committer > can turn immature vulnerabilities into real ones. We also > identified multiple factors that increase the stealthiness of the > introduced vulnerabilities, including concurrency, error paths, > aliases, indirect calls, etc. Furthermore, we provided a proofof- > concept to safely demonstrate the practicality of hypocrite > commits, and measured and quantified the risks. We finally > provided our suggestions on mitigating the risks of hypocrite > commits and hope that our findings could motivate future > research on improving the patching process of OSS. Il mito del bazaar di ESR, in cui il numero di occhi che rivede ogni riga di codice può scovare ogni bug si scontra con la realtà di software semplicemente troppo complesso per garantire davvero la libertà di comprenderlo, trasformata in un privilegio (illusorio). La criticità che NON sottolinea è: se degli studenti sono riusciti ad introdurre scientemente vulnerabilità in Linux, chi altri c'è riuscito senza farsi beccare prima di loro? Comunque Theodore Ts'o (di Google nonché membro del Technical Advisory Board della Linux Foundation dalla caduta di Linux) condanna i ricercatori ma ha già pronta la soluzione: > We do need to do a better job of reviewing patches, even "trivial" > ones, and if that means that we might need to be a bit more skeptical > dealing with newbies who are trying to get started, that's a price we > will need to pay. https://lore.kernel.org/linux-nfs/YICB3wiptvvtTeA5@mit.edu/ Insomma, anche su Linux le vulnerabilità devono essere introdotte in modo più professionale. Anche a costo di apparire meno inclusivi! (!!!) Giacomo PS: sia chiaro: il software proprietario non è più sicuro. Semplicemente nell'open source, l'introduzione delle vulnerabilità è più democratica. O meglio... lo era. PPS: ai ricercatori vanno tutta la mia stima ed i miei complimenti. Bravi: hack divertente e molto istruttivo.

April 22, 2021

Re: [nexa] How I Fought To Graduate Without Using Nonfree Software

by Andrea Trentini

On 22/04/2021 19:48, Antonio Iacono wrote: > Fosse solo il software libero il problema dell'università italiana :( ah certo, ma per mia fortuna dai "giochi dei grandi" (leggi: baronie) io sono fuori da tempo... -- |_|o|_| Andrea Trentini - http://atrent.it |_|_|o| Dipartimento di Informatica |o|o|o| Università degli Studi di Milano

April 22, 2021