December 2021 - nexa - server-nexa.polito.it

premio etic (implicazioni sociali ed etiche delle tecnologie digitali)

by Norberto Patrignani

Carissim*, segnal il bando per il premio etic che premia tesi di laurea magistrale e di dottorato di ricerca che trattano temi riguardanti le implicazioni sociali ed etiche delle tecnologie digitali https://www.aicanet.it/premio-etic saluti Norberto

Dec. 16, 2021

CfP GIG-ARTS 2022: "Global Internet Governance and International Human Rights - Whose Rights, Whose Interpretations?" 13-14 April, Nicosia

by Mauro SANTANIELLO

Dear colleagues, Please find hereafter the CFP for the GIG-ARTS 2022 conference, which will be held on 13-14 April 2022 in Nicosia (or turned to an online event if required by the sanitary situation). The full CfP (also in PDF) is available on the conference website at: events.gig-arts.eu With apologies in advance for the unavoidable cross-postings. Looking forward to your participation! Best, Mauro Santaniello ===== *GIG-ARTS 2022 - The Sixth European Multidisciplinary Conference on Global Internet Governance Actors, Regulations, Transactions and Strategies13-14 April 2022, NicosiaGlobal Internet Governance and International Human RightsWhose Rights, Whose Interpretations?* *Call for Abstracts - Deadline: 1st February 2022 * Calls for states, but also companies to ensure the compliance of digital tools and products with international human rights standards are ever-present. While this abstract goal has become somewhat of a globalist consensus, the legal, political, and institutional conditions needed to get there are far from clear: how can international human rights law initiate improvements in different areas, given its indeterminate, often even disputed nature? What are the risks of the reference to international human rights law, in terms of stabilizing preexisting disparities or power concentrations through illusive improvements? Where does the reference to human rights only provide a new, improved language for a non-improved status quo? Could private internet companies provide a protection of human rights online comparable to that of judicial institutions? Ultimately, whose human rights, and whose interpretations are determining the present and future of global internet governance? This event invites scholars and actors in the practice and policy world to re-examine and revisit the state and role of human rights in the digital world, as this is shaped by technological and political economic changes of ‘platformisation’, privatization of public spaces, erosion and abuse of certain rights, the pressure imposed on a decade of successive crises from financial, environmental to health, and the re-emergence of authoritarian politics and modes of governance. In recent years, the everyday life of humanity has been affected dramatically by the experience of a global pandemic, where public health political responses have been met with varying degrees of acceptance. The severity and nature of this impact differs greatly among regions and within societies, across genders and socioeconomic discrepancies, bringing back to the fore the persistence and deeply engrained footprint of social inequalities. Within this context of emergency, crisis and exacerbation of inequities, the digital world occupied a center stage in the social, cultural and professional spheres. The heightened physical and mental health crisis across the globe is intertwined with a long and arduous struggle in governing digital platforms for the benefit of humanity vis-a-vis the profit driven dominant model. The latter has impacted not only on the ways in which users on platforms are adjusted to the needs of the platform, systematically and technologically through the use of AI, rather than the opposite, but have also impacted on understandings and conceptualizations of fundamental freedoms and rights, as they are shaping social conceptualizations of what privacy means, the extent of free speech and hate speech, the extent of misinformation and the exercise of informational rights. After having addressed “Global Internet Governance as a Diplomacy Issue” at its first edition in 2017, “Overcoming Inequalities in Internet Governance” in 2018, “Europe as a Global Player in Internet Governance” in 2019, and “Online Information Governance” in 2020, The European Multidisciplinary Conference on Global Internet Governance Actors, Regulations, Transactions and Strategies turns its attention this year to the governance of human rights in the digital world, continuing the conversation on global internet governance from attention to institutions and structural factors to the role of content and misinformation as an object of governance, and internet actors as forces of change. In addition to general internet governance issues and topics, submissions are particularly welcome on the following possible areas of investigation: - How human rights translate in a digital world: losses, gains and shifting of priorities - Human rights duties and responsibilities of respective internet governance stakeholders - From high-level panels on digital cooperation to digital conventions: towards a new digital world order? - The role of European and global institutions in shaping the conditions of human rights and democracy online - Global platforms, conflicts of jurisdictions and extraterritorial legislations - Weaponization of platforms to interfere in political processes and harass individuals and groups - Responsibility and liability of platforms and other intermediaries in content regulation - Governance from below: practices and principles by civil society aiming to shape the conditions of technology - Restrictive regulation and the securitization of content - Structural role of individual targeting, behavioral advertising and other economic models of online platforms on the reshaping of fundamental freedoms and democracy - Privacy, misinformation, democracy: challenges to internet governance - From nudging to manipulation: consequences on autonomy and human dignity - Freedom of expression, freedom of the press and democracy - Youth and other vulnerable groups: access to information, news and misinformation in the online world *Submission information and publication Opportunities*Authors are invited to submit their extended abstracts (no longer than 500 words), describing their research question(s), theoretical framework, approach and methodology, expected findings or empirical outcome. Submitted abstracts will be evaluated through a peer-review process. Abstracts and authors’ information should be submitted through the Easychair conference management system at: *https://easychair.org/conferences/?conf=gigarts2022 <https://easychair.org/conferences/?conf=gigarts2022>* Authors of selected submissions will have the opportunity to submit their full manuscript for publication. *Conference Grant for Students*The GIG-ARTS conference and the Leibniz-Institute for Media Research | Hans-Bredow-Institut are proud to encourage the participation of emerging researchers through the HBI/GIG-ARTS Emerging Scholars Network project set up in 2022. Up to 10 exceptional submissions from emerging researchers will be selected to receive a grant of 500 EUR each, to help cover their conference participation costs. Masters or PhD Students who have not yet been awarded a PhD by the time of the conference are eligible. In addition to presenting their work at GIG-ARTS 2022, the grantees will share their research via a short blog post on the HBI’s Media Research Blog, Podcast, or another science transfer format and will join a set of network building sessions leading up to the conference. *To be considered for the grant programme, Masters or PhD students must, in addition to the abstract submission process set out above, notify the Co-Chairs of their application for the conference grant via an email to: events(a)gig-arts.eu <events(a)gig-arts.eu>*; no additional documents are required. *Key dates*- Deadline for abstract submissions: 1st February 2022 - Notification to authors: 1st March 2022 - Authors registration (at least one author must register for a selected presentation to appear on the programme): From 1st to 14 March 2022 - Programme publication: 21 March 2022 - Online registration: From 21 to 31 March 2022 - Conference dates: 13 & 14 April 2022 *GIG-ARTS 2022 Co-Organizers and Co-Sponsors*- Frederick University, Cyprus - COST Action GDHRNet - The Global Digital Human Rights Network, EU - Leibniz Institute for Media Research | Hans-Bredow-Institut, Germany - LIP6 Computer Science Research Lab, Sorbonne Université & French National Center for Scientific Research, France - The Media Governance and Industries Research Lab & Jean Monnet Centre of Excellence FreuDE, University of Vienna, Austria *GIG-ARTS 2022 Co-Chairs*- Konstantinos Kouroupis, Department of Law, Frederick University, Cyprus - Meryem Marzouki, LIP6, CNRS & Sorbonne Université, France - Katharine Sarikakis, Media Governance and Industries Research Lab & Jean Monnet Centre of Excellence FreuDE, University of Vienna, Austria and, as junior chair, - Martin Fertmann, Leibniz Institute for Media Research | Hans-Bredow-Institut, Germany *GIG-ARTS 2022 Organizing Committee*- Martin Fertmann, Leibniz Institute for Media Research | Hans-Bredow-Institut, Germany - Vassiliki Karagouni, Department of Law, Frederick University, Cyprus - Konstantinos Kouroupis, Department of Law, Frederick University, Cyprus - Meryem Marzouki, LIP6, CNRS & Sorbonne Université, France - Katharine Sarikakis, Media Governance and Industries Research Lab & Jean Monnet Centre of Excellence FreuDE, University of Vienna, Austria *GIG-ARTS 2022 Scientific Programme Committee*- Francesco Amoretti, University of Salerno, Italy - Mutlu Binark, Hacettepe, University, Turkey - Eric Brousseau, Université Paris Dauphine, France - Andrea Calderaro, Cardiff University, United Kingdom - George Christophides, Frederick University & Legal Partners, Cyprus - Dimitrios Devetzis, Frederick University, Cyprus - Martin Fertmann, Leibniz Institute for Media Research | Hans-Bredow-Institut, Germany - Louise Marie Hurel, London School of Economics, United Kingdom - Matthias Kettemann, Leibniz Institute for Media Research | Hans-Bredow-Institut, Germany & University of Innsbruck, Austria - Konstantinos Kouroupis, Frederick University, Cyprus - Joanna Kulesza, University of Lodz, Poland - Nanette S. Levinson, American University Washington DC, USA - Eva Lievens, Ghent University, Belgium - Robin Mansell, London School of Economics, United Kingdom - Meryem Marzouki, CNRS & Sorbonne Université, France - Trisha Meyer, Vrije Universiteit Brussel, Belgium - Tiina Pajuste, Tallinn University, Estonia - Stavros Parlalis, Frederick University, Cyprus - Clara Rauchegger, University of Innsbruck, Austria - Michele Rioux, Université du Québec à Montréal, Canada - Graziella Romeo, Bocconi University, Italy - Mauro Santaniello, University of Salerno, Italy - Katharine Sarikakis, University of Vienna, Austria - Yves Schemeil, Sciences Po Grenoble, France - Jan Aart Scholte, Leiden University, The Netherlands & University of Duisburg-Essen, Germany - Mart Susi, Tallinn University, Estonia *Venue*GIG-ARTS 2022 will be held at Frederick University, Nicosia Campus, situated in the Pallouriotissa area, just two kilometers from the city center. We are hopeful that we could meet there in person next Spring. However, if the sanitary conditions are such that travels are suspended, the conference will be turned into an online event. *Conference Registration and Fees*Registration fees are 100€ for regular participants and 50€ for students showing proof of status. The conference fees include a participant kit as well as coffee breaks and meals. *GIG-ARTS 2022 Communication Details*- Website: events.gig-arts.eu - Email for information: events(a)gig-arts.eu - Submissions: *https://easychair.org/conferences/?conf=gigarts2022 <https://easychair.org/conferences/?conf=gigarts2022>* - Twitter: @GigArtsEU - Hashtag: #GIGARTS22 - Mailing list for updates: http://tinyurl.com/yc7rvxm4 _________ Mauro Santaniello (PhD) *Internet & Communication Policy Centre * *Department of Political and Social Studies * *Università degli Studi di Salerno * *Via Giovanni Paolo II, 132 84084 Fisciano (SA) - Italy * *E. msantaniello(a)unisa.it <msantaniello(a)unisa.it> * *W. http://docenti.unisa.it/mauro.santaniello <http://docenti.unisa.it/mauro.santaniello>* *Skype: internetpolicy * *T. twitter.com/webvoodoo <http://twitter.com/webvoodoo>* *Recent publications* M.Santaniello (2021) "From Governance Denial to State Regulation: A Controversy-Based Typology of Internet Governance Models." In Haggart B., Tusikov N., Scholte J.A. (eds.) *Power and Authority in Internet Governance. Return of the State? *Routledge. N.Palladino, M.Santaniello (2021).* Legitimacy, Power, and Inequalities in the Multistakeholder Internet Governance. **Analyzing IANA Transition*. Palgrave Macmillan. *Pubblicazioni recenti in italiano* M. Santaniello (2021) "Fortezza Internet. L’incastellamento del cyberspazio e il regime feudale della cyber security." In Amoretti F.* Per una cultura della sicurezza democratica* Pag.131-148 Soveria Mannelli Rubbettino. F. Amoretti, M. Santaniello (2021) "Sovranità (con)tese. Le digital corporation nello spazio pubblico globale." In F.Tuccari; G. Borgognone *La sovranità* Pag.175-194 M. Santaniello (2021) "Sunburst. La grande eclissi della cybersecurity Usa." *Rivista di Digital Politics*. Vol. 1/2021. Pag.179-194. F. Amoretti, M. Santaniello (2021), "Partecipazione politica e opinione pubblica online in tempo di crisi." *Iride* Vol. 92. Pag.57-67. F. Amoretti, R. Fittipaldi, M. Santaniello (2021), "Poteri monocratici e comunicazione politica ai tempi della pandemia. Dal governo Conte II al governo Draghi". *Comunicazione politica, n. *3/2021, pp. 333-356.

Dec. 16, 2021

Re: [nexa] Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent

by 380°

Ciao Giacomo, Giacomo Tesio <giacomo(a)tesio.it> writes: [...] >> 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. > > No, Giovanni, non c'è scritto OK grazie, questa è l'ennesima cosa /grave/, considerato che - dalle parole di Volkan Yazıcı che tu hai riportato nel precedente messaggio quella è una «feature we all dislike yet needed to keep»: in una documentazione seria io mi aspetterei un avviso grande come una casa del tipo "lasciate ogni speranza o voi che usate questa feature". Anche la documentazione è parte integrante del software, solo che è quella che costa di più quindi mediamente fa schifo. Nel risk management uno dei modi di ridurre il rischio è documentarlo :-O [...] >> A dire il vero, nel 2015 [1] [2] questa classe di bachi - intendo dire >> vulnerabilità dovute alla deserializzazione - era stata evidenziata da >> due professionisti > > Le due cose non sono mutualmente esclusive: il fatto che problema delle > implementazioni della JNDI fosse noto, non implica che qualcuno abbia > letto la documentazione di log4j, notato che che venivano usate > nell'espansione dei pattern prima di scrivere i log e fatto due più > due. Quello che mi pare evidente è che in molti avrebbero potuto fare due più due /en plein air/ ma una parte ha deciso che non li riguardava e l'altra ha deciso di usarla a proprio vantaggio per bucare altri sistemi. ...solo che la gara a chi è /er più/ è decisamente perdente per tutti, anche per quelli che si illudono di essere /er mejo dei più/ convinti di riuscire a non essere "bucati", ormai di casi se ne contano a decine. Ci vorrebbe una moratoria internazionale :-D [...] > I professionisti cercano di raggiungere backup ed archivi dei clienti > in modo da installarvi subito backdoor difficilmente individuabili e > che verranno ripristinate anche in caso di ricostruzione complessiva > del software del datacenter a partire dai sorgenti (cosa che tanto > nessuno farà davvero). Già, altro tema decisamente ignorato dal giorno dopo la lezione al Turing Award «Reflections on Trusting Trust» di Ken Thompson, era il 1984. [...] Saluti, 380° -- 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>.

Dec. 15, 2021

Re: [nexa] Cina: non ha rinunciato al suo progetto per cambiare i connotati di internet | Wired Italia

by 380°

don Luca Peyron <dluca.universitari(a)gmail.com> writes: > https://www.wired.it/article/cina-internet-controllo-rete/ Da quello che capisco il documento ufficiale è questo del 2019-03-23: https://www.itu.int/md/T17-TSAG-C-0083 Titolo: "New IP, Shaping Future Network": Propose to initiate the discussion of strategy transformation for ITU-T L'accesso è riservato ai membri ITU, noi possiamo solo leggere le analisi /di parte/ (tranne la parte cinese, almeno non io che non conosco la lingua). Saluti, 380° -- 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>.

Dec. 15, 2021

Cina: non ha rinunciato al suo progetto per cambiare i connotati di internet | Wired Italia

by don Luca Peyron

Geopolitica di rete. Buona lettura Dl https://www.wired.it/article/cina-internet-controllo-rete/

Dec. 15, 2021

Re: [nexa] Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent

by Giacomo Tesio

On Tue, 14 Dec 2021 20:03:48 +0100 380° wrote: > Giacomo Tesio <giacomo(a)tesio.it> 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. No, Giovanni, non c'è scritto: il mio link voleva fornire un riferimento solo alla "feature" in questione, non all'exploit. Le mie parole erano una semplificazione (evidentemente eccessiva) di quanto spiegato meglio da Bechler qui: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ > Log4J will perform a JNDI lookup() while expanding placeholders in > logging messages (or indirectly as parameters for formatted messages). > > In a default installation there are two “interesting” protocols > supported by JNDI: RMI and LDAP. In both cases a lookup() call is > actually meant to return a Java object. This usually means serialized > Java objects, however there is also a JNDI Reference mechanism for > indirect construction through a factory. This object and factory > bytecode can potentially be loaded from a remote URL codebase (read: a > webserver with .class files). Una factory [1] è un metodo (tipicamente statico) che restituisce un'istanza di un oggetto. Per restituirla deve essere eseguito, tipicamente dalla macchina virtuale che poi userà l'istanza. E per creare l'istanza può fare tutto ciò che l'ambiente di esecuzione permette. Quindi in questo caso può scaricare altro codice etc... Scusa l'approssimazione confusa. > > 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 Le due cose non sono mutualmente esclusive: il fatto che problema delle implementazioni della JNDI fosse noto, non implica che qualcuno abbia letto la documentazione di log4j, notato che che venivano usate nell'espansione dei pattern prima di scrivere i log e fatto due più due. O meglio, ripeto: diversi l'hanno fatto, ma non sappiamo chi o da quanto tempo sfruttassero questa vulnerabilità senza farsi notare. Naturalmente, avere tutte le uova in un solo paniere (i grandi cloud provider) avrà reso molto più facile la vita degli attaccanti (che hanno sicuramente avuto almeno diversi MESI per operare). Ora tutti faranno finta che non sia successo niente: aziende, Garanti della Privacy e Governi... Ma dopo un "incidente" come questo non devi solo reinstallare TUTTI i datacenter, ma ricontrollare anche tutti i log dei backup, gli archivi del software etc... I pivelli che compromettono un datacenter installano miner bitcoin. I professionisti cercano di raggiungere backup ed archivi dei clienti in modo da installarvi subito backdoor difficilmente individuabili e che verranno ripristinate anche in caso di ricostruzione complessiva del software del datacenter a partire dai sorgenti (cosa che tanto nessuno farà davvero). Di fronte a tutto ciò, favole come il "risk management" in InfoSec servono solo a garantire la sicurezza economica di chi le racconta. Ma in fondo è così che funziona il mercato, giusto? Costose favole hi-tech per soddisfare la domanda di rassicurazione. Giacomo [1] https://en.wikipedia.org/wiki/Factory_method_pattern

Dec. 14, 2021

«Non esco più di casa». Quei figli che si tagliano fuori

by don Luca Peyron

Fenomeni in crescita, di cui ho empiricamente riscontri anche nella mia vita ordinaria di prete. Questioni che molto si intrecciano con il web, i suoi luoghi, i suoi rituali, ma non solo. Buona lettura Dl https://www.avvenire.it/famiglia/pagine/non-esco-pi-di-casa-figli-che-si-ta…

Dec. 14, 2021

Re: [nexa] Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent

by 380°

Buonasera, scusate se allungo il thread ma ci sono un paio di questioni cruciali che vorrei evidenziare Giacomo Tesio <giacomo(a)tesio.it> 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-je… «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-je… «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>.

Dec. 14, 2021

Re: [nexa] Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent

by Giacomo Tesio

Ciao Giovanni, On Tue, 14 Dec 2021 13:29:04 +0100 380° wrote: > > Chi crede che non sia stato exploitato per mesi prima di essere reso > > pubblico, non dovrebbe parlare di informatica in pubblico. > > La libertà di credenza e di parola non si deve negare a nessuno. Hai ragione. Scusate. Mi sono fatto prendere la mano dall'indignazione. Il problema è che quando questa gente parla, i non tecnici gli credono. La realtà è troppo terribile, e preferiscono essere rassicurati e rabboniti rispetto ad affrontare e risolvere i problemi. > Un elenco che /mi pare/ ben mantenuto è quello del Nationaal Cyber > Security Centrum olandese: > https://github.com/NCSC-NL/log4shell/tree/main/software > > Fa girare un po' la testa, effettivamente. > > ... Google non pervenuto?!? L'assenza di Google è interessante. L'unica spiegazione credibile che mi viene in mente è che fossero a conoscenza del problema da tempo, ma non l'avessero reso pubblico. Magari speravano nessuno ci vacesse caso! :-D Giacomo

Dec. 14, 2021

Re: [nexa] Arbitrary code execution in iCloud, Twitter, Steam, CloudFlare, Amazon, Tesla, Baidu, Tencent

by Giacomo Tesio

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/ja… [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-devic… https://www.cnet.com/tech/services-and-software/the-log4j-software-bug-coul… [13] non è impossibile: https://www.netsurf-browser.org/

Dec. 14, 2021