Buongiorno, notizia un po' tecnica ma spero abbastanza comprensibile a tutti.
https://pytorch.org/blog/compromised-nightly-dependency/ «Compromised PyTorch-nightly dependency chain» Si tratta dell'ennesimo attacco /supply chain/ causato da uno dei tanti (troppi) package manager e relativi repository progettati e implementati talmente male che davvero peggio non si può. Il succo del problema è questo: --8<---------------cut here---------------start------------->8--- At around 4:40pm GMT on December 30 (Friday), we learned about a malicious dependency package (torchtriton) that was uploaded to the Python Package Index (PyPI) code repository with the same package name as the one we ship on the PyTorch nightly package index. Since the PyPI index takes precedence, this malicious package was being installed instead of the version from our official repository. This design enables somebody to register a package by the same name as one that exists in a third party index, and pip will install their version by default. This malicious package has the same name torchtriton but added in code that uploads sensitive data from the machine. --8<---------------cut here---------------end--------------->8--- Sostanzialmente su PyPI (et al.) chiunque può caricare un pacchetto col nome che vuole e questo viene **ufficialmente** distribuito a tutti gli utenti "pip". La vulnerabilità [1] è nota da prima del Luglio 2020, ma praticamente "sconosciuta" a chi crea pacchetti PyPI; nella issue [1] ci sono anche alcuni link a casi concreti osservati, in particolare "la madre di tutte le prove": https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/ «Researcher hacks over 35 tech firms in novel supply chain attack» (Febbraio 2021) --8<---------------cut here---------------start------------->8--- Using this technique, Birsan executed a successful supply chain attack against Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp, and Uber simply by publishing public packages using the same name as the company's internal ones. [...] Knowing that his scripts would be making connections from corporate networks, Birsan decided to use DNS to exfiltrate the data to bypass detection. --8<---------------cut here---------------end--------------->8--- Quindi il fenomeno **non** è limitato a PyPI ed è talmente diffuso (e **pericoloso**) che ha un suo nome: **dependency confusion** (aka depencency hell). Quello che mi rattrista tantissimo è che distribuzioni come Debian et al [2] è da **molti** anni che lavorano per creare un ambiente di distribuzione del software (package manager e repository del software) sicuro [3] e /contemporaneamente/ aperto all'ingresso di svariati contributori... poi sono arrivati 'sti fenomeni e hanno agito come se quegli "ecosistemi software" ben progettati fossero una palla al piede, perché nella distribuzione del software bisogna essere agili e scattanti, /futuristi/ mi verrebbe da dire: che menata la sicurezza, eh?!? :-O Morale della favola: non usate PyPI, npm, RubyGems o simili per installare il vostro software, usare una distribuzione **seria**, fatevi un favore ;-) Saluti, 380° [1] https://github.com/pypa/pip/issues/8606 [2] e più di recente Nix e Guix [3] e "magari" pure riproducibile e boostrappable, sto infierendo? -- 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 nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
