Buonasera, scusate se allungo il thread ma ci sono un paio di questioni cruciali che vorrei evidenziare
Giacomo Tesio <[email protected]> writes: [...] > 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. > [6] https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLooku (ho riportato qui il link per comodità di commento) Io ho letto e riletto quattro volte quel paragrafo e - complice la mia ignoranza - non capisco dove c'è scritto che la variabile recuperata via JNDI viene usata per scaricare un payload (una classe Java?) che poi viene eseguito dal processo che lo scarica. [...] > 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. A dire il vero, nel 2015 [1] [2] questa classe di bachi - intendo dire vulnerabilità dovute alla deserializzazione - era stata evidenziata da due professionisti, tanto che Moriz Bechler scriveva nel 2017 circa: --8<---------------cut here---------------start------------->8--- It's been more than two years since Chris Frohoff and Garbriel Lawrence have presented their research into Java object deserialization vulnerabilities ultimately resulting in what can be readily described as the biggest wave of remote code execution bugs in Java history. Research into that matter indicated that these vulnerabilities are not exclusive to mechanisms as expressive as Java serialization or XStream, but some could possibly be applied to other mechanisms as well. This paper presents an analysis, including exploitation details, of various Java open-source marshalling libraries that allow(ed) for unmarshalling of arbitrary, attacker supplied, types and shows that no matter how this process is performed and what implicit constraints are in place it is prone to similar exploitation techniques. --8<---------------cut here---------------end--------------->8--- (tratto da da https://github.com/mbechler/marshalsec, dove è disponibile il paper «Java Unmarshaller Security - Turning your data into code execution» di Moritz Bechler. Nota: "marshalling" in questo contesto è sinonimo di "serialization") Vorrei sottolineare che questo bug di log4j è /solo/ una istanza delle classi di vulnerabilità denominate JNDI Injection [3], parte di una più grande classe di vulnerabilità denominate "unserialize vulnerabilities", che in un articolo [4] del 2015 venivano spiegate così: --8<---------------cut here---------------start------------->8--- Unserialize vulnerabilities are a vulnerability class. Most programming languages provide built-in ways for users to output application data to disk or stream it over the network. The process of converting application data to another format (usually binary) suitable for transportation is called serialization. The process of reading data back in after it has been serialized is called unserialization. Vulnerabilities arise when developers write code that accepts serialized data from users and attempt to unserialize it for use in the program. Depending on the language, this can lead to all sorts of consequences, but most interesting, and the one we will talk about here is remote code execution. --8<---------------cut here---------------end--------------->8--- [...] > Non c'è alcun "quadro di risk management" credibile perché l'unico > modo efficace per valutare i rischi ...è avere un sistema serio di valutazione /continua/ dei rischi sistemistici, che /ovviamente/ includa anche una valanga di studio del codice e analisi delle informazioni che provengano da un pubblico /scambio/, magari con persone alle quali piace moltissimo quel tipo di lavoro e alle quali vengano fornite adeguate risorse per svolgerlo. Se ci fosse, mi piacerebbe davvero vedere il documento di analisi dei rischi del progetto log4j: che risposta avrebbe la domanda "cosa succederebbe se il lookup JNDI caricasse codice serializzato Java" cosa rispondereste sapendo quello che ho scritto sopra? > da gestire è analizzare approfonditamente TUTTO il codice, e solo gli > hacker incuriositi da una specifica codebase e le intelligence lo > fanno davvero. E quando alcuni hacker lo raccontano non se li fila nessuno, manco di striscio. [...] > 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. Sia chiaro: infinito rispetto per le persone come Volkan Yazıcı, ci manca solo che la colpa ricada su di loro! Quindi era noto che quella "feature" era pericolosa e per non disturbare troppo (chi?) si è preferito lasciare aperta la voragine? [...] > Dunque se riduciamo la questione ad una prospettiva economica, non > abbiamo alcuna speranza di evitare che si ripeta. Sono d'accordo, si tratta innanzitutto di una questione culturale (che determina anche le politiche economiche), è una questione di civiltà informatica ma è anche strettamente connessa alla cupidigia e alla pigrizia di coloro che gestiscono l'attuale sistema di produzione informatica senza adeguati strumenti culturali e /conseguente/ redistribuzione delle risorse economiche. [...] > Per evitare che TUTTI i ponti crollino contemporaneamente, > dobbiamo smettere di costruirli sulla sabbia. Sì ma quello è facile, oserei dire banale: la questione è che dobbiamo smetterla di costruirli col CEMENTO DEPOTENZIATO e fare regolare manutenzione. ...ma noi viviamo di /marketing dell'innovazione/ --8<---------------cut here---------------start------------->8--- the story of how we devalued the work that underpins modern life—and, in doing so, wrecked our economy and public infrastructure while lining the pockets of consultants who combine the ego of Silicon Valley with the worst of Wall Street’s greed. --8<---------------cut here---------------end--------------->8--- (presentazione del libro «The Innovation Delusion» http://leevinsel.com/the-innovation-delusion) > Perché gli sviluppatori di Amazon, Apple, Tencent, CloudFlare etc... > non hanno letto il codice di log4j prima di utilizzarlo? Perché non sono pagati per fare quello, anzi io sono convinto che se i loro manager li /beccassero/ a farlo li licenzierebbero in tronco. ...in compenso ci sono /altri/ che lo leggono o lo /testano/ (per trovare bachi non è necessario leggere tutto il codice) per passione, ma generalmente contano come il due di picche a briscola. > Perché è troppo complesso. No, no, no, no: è /complicato/. Fosse solo complesso sarebbe gestibile perché le risorse necessarie aumenterebbero linearmente, quando invece è complicato le risorse necessarie a gestirlo aumentano esponenzialmente secondo il grado di complicazione. Quindi, per sparare numeri a caso, se fosse semplice nella sua complessità probabilmente ci vorrebbero un paio di settimane mentre complicato nella sua complessità non basterebbero sei mesi. [...] > Dobbiamo iniziare a scrivere software più semplice (non > necessariamente più facile) che gli utenti possano sempre studiare, > comprendere e modificare in tempi ragionevoli. Sono molto d'accordo con Giacomo, la /complicazione/ del software, dal /microcode/ in su, sta diventando un problema sempre più ingestibile. Mi piacerebbe sentire cosa ne pensano le persone nexiane che insegnano informatica in università. [...] > Insomma la soluzione è semplice, ma non facile. Giusto, la soluzione facile è quella usata fino ad ora: aggiungere pezze su pezze aumentando la complicazione del software e sperando che non crolli tutto alla prima folata di vento. [...] Ci /sarebbe/ tanto bel lavoro da fare, ma siamo tutti /troppo/ impegnati a fare altro. Saluti, 380° [1] http://frohoff.github.io/appseccali-marshalling-pickles/ «AppSecCali 2015: Marshalling Pickles - how deserializing objects will ruin your day» [2] https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ «What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.» [3] https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ «PSA: Log4Shell and the current state of JNDI injection» [4] https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability «What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.» -- 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>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list [email protected] https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
