Le dépôt Python package index attaqué
Le 22 mai 2023 à 05h08
2 min
Logiciel
Logiciel
Samedi 20 mai, la création de comptes et l'ajout de nouveaux projets ont été suspendus par les responsables du Python Package Index (PyPI), le dépôt tiers officiel du langage de programmation Python, a remarqué The Hacker News.
Un message accessible via la page d'accueil du dépôt expliquait que « Le nombre d'utilisateurs et de projets malveillants créés sur l'index au cours de la semaine dernière a dépassé notre capacité à y répondre en temps opportun, en particulier alors que plusieurs administrateurs PyPI sont en congés ».
PyPI ne donne pas plus de détails sur ces attaques mais Hacker News interprète cette décision comme la preuve que le dépôt est devenu une cible populaire chez les pirates pour « empoisonner » la chaine de production des logiciels.
Le média a aussi signalé la semaine dernière que la startup israélienne Phylum avait découvert une campagne de logiciels malveillants. Celle-ci utilise notamment un paquet permettant une interaction avec chatGPT qui récupère aussi les jetons Discord, pour ensuite voler le contenu du presse-papiers afin de détourner les transactions de crypto-monnaie.
La suspension a été levée au cours de la nuit de dimanche à lundi.
Le 22 mai 2023 à 05h08
Commentaires (19)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 22/05/2023 à 05h14
Au même titre que le repo NPM, PyPi est une cible de choix en effet. C’est pour ça qu’il faut soigneusement choisir ses dépendances, et aussi, utiliser des outils de SCA/SAST.
Et entre les dépendances bourrées de malwares, celles qui font de l’exfiltration de donnée, ou encore les revendications politiques, on a pas le cul sorti des ronces.
Le 22/05/2023 à 06h40
Tu aurais des conseils concernant ce type de logiciels ? (SCA/SAST)
Le 22/05/2023 à 08h52
sur l’analyse de code, tu trouveras plein d’outils listés ici. Il s’agit d’une liste proposée par la fondation OWASP, je pense qu’ils sont plutôt agnostiques.
Pour les dépendances, le même organisme propose une autre liste d’outils ici.
Ils précisent pour chaque outil le type de licence (libre / gratuit / commerciale).
Dans mon souvenir j’avais ajouté à un Jenkins un plugin qui récupérait sur les repos OWASP les listes de librairies vulnérables. C’est quelque chose qu’il était possible d’inclure dans des builds Maven, mais pour être honnête… ça date, je n’ai pas suivi le sujet depuis quelques années. Et je crois bien que c’était limité à Java.
Le 22/05/2023 à 09h16
Merci pour les listes, je n’avais pas eu la curiosité de chercher ça sur leur site.
Le 22/05/2023 à 16h16
En gratuit le choix va être vite limité car une bonne partie de ces solutions sont payantes (et je reconnais avoir peu de recul sur les solutions libres / gratuites). Mais de mon expérience voici ceux dont je peux parler.
Pour les utilisateurs de GitHub, la Advanced Security est gratuitement accessible pour les repositories publics (certaines fonctions restent uniquement sur l’offre payante, mais l’essentiel est là dont l’analyse de secrets). Elle comprend l’analyse sécurité du code (SAST) avec CodeQL et l’analyse de dépendances (SCA) avec Dependabot et le scan de secrets. Concernant le SCA, Depandabot est gratuit dans tous les cas, l’Advanced Security n’a quasi rien de plus à lui apporter en dehors d’un dashboard pas spécialement meilleur. Sa force est surtout de proposer des pull request avec les dépendances considérées comme non trouées (son mode “version update” permet la mise à jour régulière des dépendances sans lien direct avec la sécu). Pour les repos et orga privés, la solution est payante par nombre de sièges au committer sur l’orga (c’est quasi toujours le même business model pour ces outils).
GitLab aussi a une offre sécurité comme celle de GitHub, qui inclus en plus le DAST (analyse d’application en fonctionnement) si je ne m’abuse, ce que GitHub ne fait pas. Je n’ai pas d’expérience avec cependant.
SonarQube, bien qu’historiquement un outil d’analyse qualité de code, s’est lancé sur le créneau SAST ces dernières années et commence à avoir une bonne crédibilité de mon expérience. Le produit a l’avantage d’être open source et la version Enterprise apporte des langages supplémentaires (genre COBOL toussa) en plus évidemment des features entreprise usuelles. SonarCloud est gratuit pour les projets publics.
Veracode, assez peu d’expérience dessus, mais les quelques démo que j’ai eu à son sujet montrent une suite assez puissante, mais aussi chère. De mémoire ils incluent dans la partie SCA la notion de “réputation” du mainteneur, en lien avec les libs qui ont été sabotées en signe de protestation politique (comme les devs qui ont saboté les libs si utilisées par des postes identifiés comme russes par exemple).
Checkmarx est aussi un gros du marché, mais à ce jour je n’ai pas d’expérience avec.
Et je plussoie le message #9, vous pouvez générer le SBOM et le faire analyser par OWASP, c’est déjà un bon point d’entrée.
A noter que côté GitHub, ce qui se dessine et sans aucune surprise vu l’investissement de Microsoft dans le domaine, c’est que Copilot intègre la suite sécurité en étant capable de proposer des corrections de code. Aujourd’hui la plupart des solutions ne sont capables de donner que des exemples de remédiation, mais avec l’IA générative ça va évoluer.
Le 22/05/2023 à 18h44
merci beaucoup !
Le 22/05/2023 à 06h22
Oh je ne connaissais pas ce type d’outils, je vais me renseigner, merci !
Le 22/05/2023 à 06h49
J’ai vraiment du mal avec les langages actuels (y compris .Net): TOUT est sous forme de package optionnel. Même des fonctionnalités basiques qui font partie 10 fois de l’OS (genre… les packages XML/JSON que certains projets utilisent).
On télécharge des dizaines (voire centaines) de Mo de packages et dépendances juste pour faire un serveur Web (qui est une chose “assez” basique) et on ne maîtrise plus rien.
Même RUST est basé sur ce type de comportement: je suis de l’ancienne école: quand j’installe un environnement de dev, je veux que des packages standards soient sur mon ordi, avec la doc, et que leur version change une fois tous les 2 ans au plus (j’accepte les mise à jour intermédiaires de sécu bien sûr).
L’écosystème python, si on n’est pas plongé dedans, c’est la caricature du dev actuel. Les exemples font télécharger plusieurs librairies, et python n’est pas le plus utile du tout, c’est une librairie particulière qui fait le taf, et soit elle n’est pas open source, soit elle contient une partie closed source sous forme de DLL voire discrètement de service web…
Le 22/05/2023 à 12h24
Pour Python, l’un de slogan du langage, c’est “batteries included”. Python vient avec tout ce qu’il faut. Les bibliothèques de base de Python sont en effet assez bien fournies et je pense dépasse largement ce que l’on trouve dans la bibliothèque standard de C++ par exemple.
Cependant, avec Python, il y a 2 choses :
Par exemple, un paquet tiers très connu en python, c’est numpy. Le truc permet de manipuler des “arrays” similaire au tableau C avec l’efficacité comparable au C/C++ mais avec la souplesse de Python. Le paquet est très bien documenté, très connus, avec une grosse commu, permet de manipuler des tableaux de donnée dans tous les sens, s’interface en toute transparence avec python et il est performant. Il s’est imposé comme un incontournable dans la manipulation de donnée.
En conclusion, Python seul est largement capable de faire ce que tu veux. Mais il y a tellement de bons paquets qui complètent les bibliothèques de bases et les outils fournis avec python facilite leur utilisation que tout le monde utilise ces paquets tiers.
Le 22/05/2023 à 07h12
Je partage ce constat :-(
D’autant que ça fait doublon avec le gestionnaire de package de l’OS , ce qui mène à bien des situations merdiques .
En ce moment je me mets au Rust et je suis déçu effectivement de ce choix.
(Après mon objectif est plutôt d’utiliser Rust dans un environnement noyau et / ou microcontroleur, donc là, les libs de cargo… )
Tu as un exemple ? Je travaille pas mal en python (pas sous windows il est vrai) et j’ai pas rencontré de cas où PIP tire un package closed-source.
(Ce qui n’enlève rien aux inconvénients cités, vu que la force de l’opensource est justement de pouvoir analyser le code, mais si personne ne fait cette analyse…)
Le 22/05/2023 à 08h00
Niveau Python, il y a tout de même de quoi faire avec ce qui est inclus et qq packages standards. Maintenant, si on ne veut pas réinventer la roue, la richesse de ce qui est dispo en librairies participe au succès de ce language… dont les propres évolutions ont aussi posé pb sans même besoin d’une tétrachiée de dépendances ingérables et pas forcément maintenues dans la durée.
=> Le pb n’est à mon sens pas qu’un problème de langage, tous permettraient de minimiser au maximum les dépendances (un peu comme coder en C avec rien au delà de la libc, tout de même, stable comme un roc niveau ABI). C’est plus un pb de développeurs troquant la facilité/rapidité à court terme contre le foutoir de maintenance à long terme à mon sens.
Question de champ d’application aussi: Python pour faire tout ce qui devient difficile à impossible à scripter en shell, ok. Pour des projets complexes à maintenir longtemps, on sort clairement du cadre “super script” et c’est là que voguera, voire un jour coulera, la galère…
Le 22/05/2023 à 08h09
Perso, pour python, je me colle une première limite à ce que propose la distro niveau packages python. Au moins on a en prime une cohérence avec l’interpréteur et le reste ainsi que des dépendances à priori maintenues dans le temps sinon un mainteneur ne se ferait pas chier à s’en occuper. Sous windows, sans doute qu’on ne peut gère se passer de PyPI mais sous une distro Linux majeure (Debian dans mon cas) on s’en passe très bien.
Cette approche permet aussi d’éviter les dégueulasseries types environnement virtuels afin de gérer le truc à la mode Java ou in-fine, le bordel était arrivé a un tel point que chaque applicatif tirait sa JVM dans la version validée avec toutes ses dépendances dans les versions ad-hoc. Et si un truc codé par un véritable gougnafier a besoin de tout cela, je passe mon chemin…
Le 22/05/2023 à 09h08
Pour SCA / SAST, vous pouvez générer un SBOM (format CycloneDX conseillé) puis donner celui-ci à manger à DependencyTrack (outil OWASP) afin qu’il monitore les nouvelle vulnérabilités trouvées sur les libs que vous utilisez. C’est ce que je fais en Java.
Avant j’utilisait Dependency Check mais c’etait au moment du build avec une fuzzy logic pas des plus heureuses et reproductible.
Le 22/05/2023 à 09h42
La fragmentation en package permet au projet principal de proposer de grandes libraries sans mettre nécessairement beaucoup d’effort de dev, de maintenance et de gestion: les efforts se répartissent naturellement en fonction des besoins, tendances et disponibilités de la communauté.
L’effet négatif, accepté par tous, c’est la dilution de la responsabilité. Et donc le risque de détournement du code par un tiers (comme ici). C’est pas pour rien que tous ces projets cherchent des solutions pour sécuriser/authentifier leur chaine de distribution.
Le 22/05/2023 à 10h14
Dommage qu’on n’ait pas plus de détails. J’aurais aimé savoir si cette “attaque” était similaire à celle sur PyTorch il y a quelques mois : https://www.bleepingcomputer.com/news/security/pytorch-discloses-malicious-dependency-chain-compromise-over-holidays/
Par contre pas d’accord avec le point de vue qui considère Python comme un langage “bon qu’à faire des scripts” : on peut tout à fait faire des projets complexes là-dessus, du moment qu’on a une bonne gestion de projet (ce qui implique de ne pas prendre n’importe quelles dépendances…). Ce n’est pas parce que Python est facile à prendre en main (et j’ai dit “facile à prendre en main”, pas “facile à maîtriser”) et qu’il est souvent utilisé pour du scripting qu’il n’est pas comparable à d’autres langages comme node.js ou Java.
Le 22/05/2023 à 10h59
Notons que bientôt cette dilution de responsabilité aura bientôt vécu, l’U.E. préparant un règlement “Cyber Resilience Act”, il serait beaucoup plus facile pour les utilisateurs de logiciels de se retourner contre un éditeur, distributeur, importateur ou fabriquant de logiciel en cas de problème de sécurité: les entreprises européennes pourraient faire valoir leurs préjudices et obtenir dédommagement devant le tribunal.
Les gestionnaires de dépôts comme Pypi, Maven Central, NPM ou même GitHub pourraient donc avoir à répondre devant la justice en cas de diffusion de logiciel non agréé (oui, le texte prévoit aussi la certification des logiciels par des organismes de contrôle avant distribution) , non finalisé, vulnérable ou malfaisant.
Le 22/05/2023 à 11h09
Le texte se limite pour l’instant aux logiciels développés/fournis dans le cadre d’une activité commerciale, définie comme étant de la monétisation directe ou indirecte (publicité…).
Reste à savoir quel est le modèle financier de ces dépôts.
https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:52022PC0454
Le 22/05/2023 à 12h15
Le texte semble avoir une bonne intention, mais la formulation est mauvaise, dénote un problème de compréhension des mécanismes du développement du libre et du coup laisser peser un risque énorme sur différents acteurs.
Le texte du règlement est suffisamment flou sur ce qui est et n’est pas concerné par le texte pour mettre la communauté libre et open source en état d’alerte. En gros, donner le logiciel gratuitement avec une licence libre ne suffit pas, le simple fait de recevoir des fonds à un moment ou un autre (un don, une bourse, un concours, un bug bounty, …) pourrait faire rentrer un logiciel ou un distributeur de logiciel dans ce ‘cadre commercial’ et provoquer l’application de tout le texte.
En pratique il y a déjà eu de nombreux avis dans la communauté, venant entre-autres d’acteurs de l’Apache foundation et de l’Eclipse foundation qui après une longue analyse, dénoncent le texte actuel et le risque inconsidéré qu’il fait courir.
(cfr: https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ , https://blog.sonatype.com/can-the-open-source-community-save-europe-from-the-cyber-resilience-act, https://blogs.eclipse.org/blogs/mike-milinkovich, …)
Il ne faut pas se leurrer de toutes façons. Si le texte fait courir un risque démesuré aux dépôts ou aux auteurs/contributeurs de logiciels, il est probable que ceux-ci prennent des mesures défensives.
Le 22/05/2023 à 15h09
Oui, je me suis mal exprimé. C’est la doc qui ne va pas et/ou les usages. Que ce soit en python, C#, même C++, on trouve des tutos qui utilise des librairies magiques que les auteurs essaient de pousser. Alors que si on lit la doc, on a déjà de quoi faire avec le langage.
Sauf que pour C#, je crois qu’il n’y a plus de doc téléchargeable (avant en Java, j’avais la doc java sur mon poste, idem pour .Net jusque v4).
C’est assez terrible en fait: si on suit les exemples d’internet, il faut apprendre x bibliothèques (une par exemple) qui font télécharger y dépendances. On démarre vite, mais on alourdi l’appli ET son apprentissage.