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-b... O **meglio ancora* leggere direttamente le sue parole: https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ Giacomo Tesio <giacomo@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é.