Ciao Stefano, grazie per l'ottima domanda! ;-)
On Tue, 14 Dec 2021 11:13:10 +0000 Stefano Traverso wrote: > In particolare, come credi che questo tipo di incidenti sia evitabile? più o meno nello stesso modo in cui si evita che tutti i ponti crollino contemporaneamente ogni 2 o 3 anni! Perché, sia chiaro: è esattamente quello che succede in informatica! Periodicamente, crolla TUTTO. Nel caso specifico, la vulnerabilità [1] è causata da una _feature_ di log4j [2] che integra i log eseguendo sostituzioni previste in configurazione DOPO aver integrato nel log l'input dell'utente. Questo è ovviamente il primo è fondamentale bug che ha reso possibile questa vulnerabilità. E come sai si tratta dell'ABC della sicurezza: l'input non va mischiato con la configurazione se quella configurazione influenza l'esecuzione. [3] Per quanto posso capire leggendo rapidamente le patch in questione [4] ed i test [5], questo problema NON è ancora stato corretto. Il che è un po' come trovare un ordigno bellico nelle fondamenta di un grattacelo, ed invece di smantellarlo, spostarlo un po' per rendere un po' più difficile accedere l'innesco. A questo primo problema fondamentale, si è aggiunta una particolare tipologia di integrazione dei log che scarica ed esegue una libreria java [6] all'interno della JVM in esecuzione. Di nuovo, non ci vuole un genio a capire che questa "feature" è andarsi a cercar grane con il lanternino: nella migliore delle ipotesi, scarica un binario a discrizione del configuratore e lo esegue nel contesto di una applicazione che NON è stata progettata per esso. Dulcis in fundo, questa integrazione automatica dei log è stata abilitata di default (terzo problema). Ora, errare è umano. Per questo i bug sono una caratteristica normale del codice. Qui abbiamo tre errori che non sono "di codice" ma "di design"! E si tratta di tre errori EVITABILISSIMI, quasi sorprendenti nella loro banalità, quasi l'ABC di come NON scrivere un programma per terze parti: - non mischiare configurazione ed input - non eseguire input non validato - non eseguire input by default Ora, giustamente, questo software open source è distribuito "WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND", quindi prendersela con gli sviluppatori significa nascondere la testa sotto la sabbia, fingendo di non vedere il problema sistemico dell'informatica contemporanea. Infatti NESSUNO di coloro che ha usato log4j nell'ultimo decennio ha - letto la documentazione di questa feature - letto il sorgente - acceso il cervello O meglio, qualcuno l'ha fatto: quelli che hanno iniziato a exploitarlo. Questo ci dice che l'approccio (o meglio, la retorica) "InfoSec" alla sicurezza informatica non può funzionare: On Tue, Dec 14, 2021 at 12:42:35PM +0100, Roberto Reale wrote: > L'informatica è fatta di bug almeno quanto di feature. > > Ciò da cui non si può prescindere è una adeguata gestione degli > incidenti, all'interno di un quadro di risk management. Non c'è alcun "quadro di risk management" credibile perché l'unico modo efficace per valutare i rischi da gestire è analizzare approfonditamente TUTTO il codice, e solo gli hacker incuriositi da una specifica codebase e le intelligence lo fanno davvero. On Tue, 14 Dec 2021 13:55:38 +0100 Stefano Zacchiroli wrote: > Il punto principale è (come lo fu, questo si, nel caso di Heartbleed) > un'intera industria IT composta di giganti for-profit che dipendono da > software libero manutenuto da 3 volontari nel loro tempo libero: Stefano Zacchiroli ha sicuramente ragione su questo, il mercato sfrutta irresponsabilmente il lavoro altamente qualificato di moltissimi sviluppatori di software libero e di software open source. Ma questo fatto non è sufficiente a spiegare il ripetersi di questi incidenti. Ad esempio la Apache Software Foundation riceve notevoli contributi da Amazon, Google, Microsoft, Tencent, Facebook, Huawei [7]. Eppure questi soldi non arrivano agli sviluppatori. Ma anche se arrivassero? Volkan Yazıcı su twitter ha scritto [9]: > Log4j maintainers have been working sleeplessly on mitigation > measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is > stopping people to bash us, for work we aren't paid for, for a > feature we all dislike yet needed to keep due to backward > compatibility concerns. A chi credete che importi quella "backward compatibility"? Proprio alle aziende che DOVREBBERO pagare lo sviluppo del software open source e del software libero che utilizzano. Dunque sebbene sia CORRETTO ricondurre il problema ANCHE al profitto sottratto agli sviluppatori dalle aziende [10], affrontare solo questo aspetto non sarebbe sufficiente ad evitare questi problemi. Chromium è un progetto open source sviluppato a tempo pieno da sviluppatori fra i più pagati al mondo. Eppure è un colabrodo [11]. Dunque se riduciamo la questione ad una prospettiva economica, non abbiamo alcuna speranza di evitare che si ripeta. Ma allora è inevitabile? No. Bisogna cambiare prospettiva. Per evitare che TUTTI i ponti crollino contemporaneamente, dobbiamo smettere di costruirli sulla sabbia. Perché gli sviluppatori di Amazon, Apple, Tencent, CloudFlare etc... non hanno letto il codice di log4j prima di utilizzarlo? Perché è troppo complesso. Ed ancora più complesso è il software in cui lo hanno integrato, insieme a migliaia di altre librerie e programmi che non hanno letto o analizzato, ma su cui basano la sicurezza informatica di clienti ed utenti. Se i CEO di queste aziende dovessero (e per me, dovrebbero) rispondere PENALMENTE di data breach come quelli che stanno avvenendo in questo istante [12], semplicemnte chiuderebbero perché, con lo stack attuale, i costi sarebbero insostenibili anche per i BigTech. Ma queste esternalità sono incomprensibili ai più, per cui ce ne facciamo carico collettivamente, mentre loro privatizzano i profitti. Tuttavia questa complessità è davvero insostenibile. Non solo economicamente, ma socialmente e politicamente. Fortunatamente basta ridurla. :-) Dobbiamo iniziare a scrivere software più semplice (non necessariamente più facile) che gli utenti possano sempre studiare, comprendere e modificare in tempi ragionevoli. Un browser che qualsiasi utente può leggere, comprendere e modificare (ad esempio) in un mese, farà molte meno cose di quelle che fa Chrome, ma le farà molto meglio [13]. Non potrà implementare standard progettati da Google per monopolizzare il controllo dei browser, e questo è un netto vantaggio per tutti (tranne che per il povero Google, ovviamente :-D) Altri software similmente semplici svolgeranno altre funzioni. Naturalmente è necessario che anche gli utenti siano messi in condizione di comprendere il sorgente di un software. Insomma la soluzione è semplice, ma non facile. L'unica alternativa però è peggiore: lo status quo... imbellettato. Giacomo [1] https://en.wikipedia.org/wiki/Log4Shell [2] https://logging.apache.org/log4j/2.x/manual/lookups.html [3] vi sono ovviamente eccezioni a questo principio generale, per esempio una shell esegue nello stesso contesto la propria inizializzazione e l'input dell'utente, ma questo è accettabile perché entrambi sono scritti dalla stessa persona. [4] https://logging.apache.org/log4j/2.x/security.html https://issues.apache.org/jira/browse/LOG4J2-3201 https://issues.apache.org/jira/browse/LOG4J2-3198 [5] https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/test/java/org/apache/logging/log4j/core/pattern/MessagePatternConverterTest.java#L79-L126 [6] https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLooku [7] https://www.apache.org/foundation/thanks.html [8] https://logging.apache.org/log4j/2.x/thanks.html [9] https://twitter.com/yazicivo/status/1469349956880408583 [10] Scommetterei un caffè che Filippo Valsorda (di Google) non è consapevole di quanto Marxista sia questa riduzione del problema https://twitter.com/FiloSottile/status/1469441477642178561 [11] https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 [12] https://www.zdnet.com/article/log4j-flaw-puts-hundreds-of-millions-of-devices-at-risk-says-us-cybersecurity-agency/ https://www.cnet.com/tech/services-and-software/the-log4j-software-bug-could-put-your-favorite-sites-at-risk-what-you-need-to-know/ [13] non è impossibile: https://www.netsurf-browser.org/ _______________________________________________ nexa mailing list [email protected] https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
