Buongiorno, la notizia è "vecchia" (9 Feb 2021) ma non mi pare passata in lista. Io sono _certo_ che il problema rigrarda tutti noi e mi piacerebbe che - almeno spiritualmente - la cosa sia sentita anche al di fuori dei "ristretti" circoli dei progrrammatori. Simili questioni riguardano _tutti_ perché coinvolgono anche "Developers Italia", anche il GARR, anche i servizi erogati dalla PA, anche le banche... e così via, perché oggi è praticamente impossibile mettere assieme una "web app" senza incappare in simili problemi. Succinta introduzione per chi non sapesse cosa sono "npm", "pip" o "rubygem": sono programmi che servono a installare altri programmi da "stores" dedicati; possono installare intere applicazioni utente oppure - come nei casi descritti nell'articolo - installare librerie utilizzate in altre applicazioni, quindi sono *ampiamente* usate come vettore per un "supply chain attack" per tentare di compromettere interi sistemi, compresi quelli di build del software distribuito attraverso altri canali, tipo quelli degli aggiornamenti ufficiali. Da qualche anno a questa parte, siccome il ciclo di distribuzione "tradizionale" [1] del software è impegnativo e molti sviluppatori non ne vogliono proprio sapere perché devono assolutamente distribuire il software... ieri, sono fioriti sistemi - uno per ciascun linguaggio di programmazione (javascript con npm in testa) - che consentono di caricare qualsiasi software semplicemente aprendo un account in uno di quegli store, dando al proprio pacchetto *qualsiasi* nome ancora disponibile (namespacing what?!?) e distribuendolo ad altri utenti e programmatori in modo da creare una catena intricatissima (dependency hell) di dipendenze tra pacchetti, ciascuno con la propria versione, spesso aggiornati "a manetta" come se non ci fosse un domani (e come se non esistesse proprio la questione del "Trusting Trust" dal 1980 circa). Io pensavo che la situazione fosse già abbastanza malmessa, però l'autore del post che vi inoltro ha illustrato che davvero non c'è limite al peggio e ora non solo esiste il "dependency hell", esiste il... "Dependency Hell Confusion" (sigla coniata da me, distribuita in Public Domain). ...sembra il titolo di un film horror :-D Ovviamente fioccheranno gli howto qui e howto la su come fare lo slalom [2] per evitare di cambiare pista (adottare un sistema decente di distribuzione del software), però questo tipo di problemi è presente *da anni* [3] nel mondo del software libero e non: poco, pochissimo viene fatto per *stroncarlo* definitivamente; cosa ci sara mai di così complesso che lo impedisce?!?! (io ho qualche sospetto e _non_ c'entra con la malizia o i servizi segreti) Se pensate che questo sia un problema solo di alcuni "smanettoni" che mettono insieme codice come hobby nel fine settimana vi sbagliate di grosso perché l'autore del pezzo parla, con discrezione, di colossi "Big Tech" come PayPal, Apple e Microsoft. La cosa divertente è che nel giro di poche ore dalla pubblicazione dell'articolo un sacco di imitatori - probabilmente a caccia di una delle innumerevoli succulente taglie sui bug - si sono precipitati a fare la stessa cosa [4] [5] con 1500 pacchetti npm e 3653 pacchetti pip [6] - subito rimossi dal repository PyPI - in un giorno. Ah, giusto per essere chiari: non è che non ci sia soluzione eh, la soluzione l'hanno "scoperta" anni fa quelli che si occupano, appunto, di distribuzioni software. ...e dopo il mio bello sproloquio, ecco l'articolo in questione: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies The Story of a Novel Supply Chain Attack Alex Birsan, 9 Feb 2021 --8<---------------cut here---------------start------------->8--- [...] Results The success rate was simply astonishing. From one-off mistakes made by developers on their own machines, to misconfigured internal or cloud-based build servers, to systemically vulnerable development pipelines, one thing was clear: squatting valid internal package names was a nearly sure-fire method to get into the networks of some of the biggest tech companies out there, gaining remote code execution, and possibly allowing attackers to add backdoors during builds. This type of vulnerability, which I have started calling dependency confusion, was detected inside more than 35 organizations to date, across all three tested programming languages. The vast majority of the affected companies fall into the 1000+ employees category, which most likely reflects the higher prevalence of internal library usage within larger organizations. Due to javascript dependency names being easier to find, almost 75% of all the logged callbacks came from npm packages — but this does not necessarily mean that Python and Ruby are less susceptible to the attack. In fact, despite only being able to identify internal Ruby gem names belonging to eight organizations during my searches, four of these companies turned out to be vulnerable to dependency confusion through RubyGems. One such company is the Canadian e-commerce giant Shopify, whose build system automatically installed a Ruby gem named shopify-cloud only a few hours after I had uploaded it, and then tried to run the code inside it. The Shopify team had a fix ready within a day, and awarded a $30,000 bug bounty for finding the issue. Another $30,000 reward came from Apple, after the code in a Node package which I uploaded to npm in August of 2020 was executed on multiple machines inside its network. The affected projects appeared to be related to Apple’s authentication system, externally known as Apple ID. When I brought up the idea that this bug may have allowed a threat actor to inject backdoors into Apple ID, Apple did not consider that this level of impact accurately represented the issue and stated: Achieving a backdoor in an operational service requires a more complex sequence of events, and is a very specific term that carries additional connotations. However, Apple did confirm that remote code execution on Apple servers would have been achievable by using this npm package technique. [...] --8<---------------cut here---------------end--------------->8--- Saluti, Giovanni. [1] tipo tutte quelle attività noiose che svolgono i mainteiners dei pacchetti delle varie distribuzioni [2] https://github.blog/2021-02-12-avoiding-npm-substitution-attacks/ [3] https://link.springer.com/chapter/10.1007%2F978-3-030-52683-2_2 «Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks» [4] https://www.bleepingcomputer.com/news/security/copycats-imitate-novel-supply... [5] https://blog.sonatype.com/pypi-and-npm-flooded-with-over-5000-dependency-con... [6] https://www.theregister.com/2021/03/02/python_pypi_purges/ -- Giovanni Biscuolo Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché.