Environ la moitié des bibliothèques Python de PyPI ont des problèmes de sécurité, affirment les boffins finlandais

  • FrançaisFrançais



  • Boffins en Finlande a analysé les bibliothèques de logiciels open source dans le Python Package Index, mieux connu sous le nom de PyPI, à la recherche de problèmes de sécurité et a découvert que près de la moitié contiennent du code potentiellement vulnérable.

    Dans un document de recherche distribué via ArXiv, Jukka Ruohonen, Kalle Hjerppe et Kalle Rindell de l’Université de Turku décrivent comment ils ont soumis quelque 197 000 packages Python disponibles via PyPI à un outil d’analyse statique appelé Bandit et ont trouvé plus de 749 000 instances de code non sécurisé.

    « Même sous les contraintes imposées par l’analyse statique, les résultats indiquent [the] prévalence des problèmes de sécurité; au moins un problème est présent pour environ 46% des packages Python », ont déclaré les chercheurs.

    Parmi les problèmes identifiés, la plupart (442 373) sont de faible gravité. Environ 227 426 sont de gravité modérée, présents dans environ 25 % des packages PyPI. Et environ 80 065 sont de gravité élevée, présents dans environ 11 % des packages PyPI.

    Sur les 46 % de colis présentant des problèmes, le nombre médian de problèmes est de trois. Mais quelques paquets étaient bien pires que la plupart.

    « Tout au bout de la queue, il y a cinq packages avec plus d’un millier de problèmes détectés : PyGGI, appengine-sdk, genie.libs.ops, pbcore, et genie.libs.parser, respectivement », indique le journal.

    Parmi ces pires contrevenants, bon nombre des problèmes détectés n’étaient pas particulièrement préoccupants. Par exemple, les boffins ont dit que tous les 2 589 problèmes avec PyGGI ont à voir avec la construction “essayer-sauf-passer”, qui, selon eux, pourrait être plus un modèle déconseillé (une “odeur de code”) qu’une vulnérabilité confirmée.

    Mais appengine-sdk, une version non officielle du kit de développement Python de Google pour son service cloud App Engine, a présenté des problèmes plus graves. Parmi les 2 356 problèmes détectés, 395 font référence à des problèmes génériques à risque connus, 351 sont liés à l’injection, 500 concernent des scripts intersites potentiels et 7 impliquent des protocoles réseau potentiellement non sécurisés.

    « Bien que ces observations s’expliquent en partie par le fait que appengine-sdk intègre une grande quantité de bibliothèques tierces directement dans sa base de code, un examen plus approfondi révèle de nombreuses pratiques de codage problématiques et potentiellement non sécurisées également dans le propre code de Google », indique le document, confondant évidemment ce projet non officiel avec celui que Google maintient.

    D’autres enquêtes de ce type sont parvenues à des conclusions similaires sur les écosystèmes de progiciels. En septembre dernier, un groupe de chercheurs de l’IEEE a analysé 6 673 applications Node.js activement utilisées et a découvert qu’environ 68 % dépendaient d’au moins un package vulnérable.

    En mars dernier seulement, PyPI a purgé 3 653 packages malveillants après que quelqu’un a créé un compte nommé “RemindSupplyChainRisks”, apparemment pour montrer à quel point il est facile d’empoisonner PyPI avec de mauvais packages.

    La situation est similaire avec les registres de packages tels que Maven (pour Java), NuGet (pour .NET), RubyGems (pour Ruby), CPAN (pour Perl) et CRAN (pour R).

    Dans une interview téléphonique, Ee W. Durbin III, directeur de l’infrastructure à la Python Software Foundation, a déclaré Le registre, “Des choses comme celle-ci ont tendance à ne pas être très surprenantes. L’une des parties les plus négligées ou mal comprises de PyPI en tant que service est qu’il est destiné à être librement accessible, librement disponible et librement utilisable. Pour cette raison, nous ne faisons aucun des garanties sur les choses qui y sont disponibles.

    Le problème de la bibliothèque

    Les logiciels modernes ont tendance à s’appuyer sur des bibliothèques open source écrites par des tiers qui ont à leur tour incorporé d’autres bibliothèques en tant que dépendances dans leurs projets. Pendant ce temps, les créateurs de logiciels malveillants ont reconnu à quel point les logiciels sont approuvés par défaut – car il n’existe aucun moyen pratique de vérifier des dizaines de packages et de nombreux niveaux de dépendances – et ont intensifié leurs efforts pour subvertir le système.

    En 2018, le fournisseur de sécurité SonaType a signalé que les vulnérabilités de la chaîne d’approvisionnement des logiciels open source avaient doublé au cours des 12 mois précédents. Et aujourd’hui, à la suite des attaques de SolarWinds et Kaseya sur la chaîne d’approvisionnement, entre autres, il est clair que les vulnérabilités des systèmes de développement de logiciels et des outils de construction nécessitent une attention encore plus grande.

    Durbin a salué le travail des chercheurs finlandais parce qu’il sensibilise les gens aux problèmes courants parmi les systèmes de gestion de paquets ouverts et parce qu’il profite à la santé globale de la communauté Python.

    “Ce n’est pas quelque chose que nous ignorons, mais ce n’est pas non plus quelque chose que nous avons historiquement eu les ressources pour entreprendre”, a déclaré Durbin.

    Ce sera peut-être moins un problème à l’avenir. Selon Durbin, il y a eu beaucoup plus d’intérêt au cours de la dernière année pour la sécurité de la chaîne d’approvisionnement et ce que les entreprises peuvent faire pour améliorer la situation.

    Pour la communauté Python, cela se traduit par un effort pour créer une API de rapport de vulnérabilité de package et la base de données de conseil Python, un référentiel géré par la communauté d’avis de sécurité PyPI qui est lié à la base de données de vulnérabilité ouverte dirigée par Google.

    « Nous sommes vraiment enthousiasmés par les opportunités présentées par la base de données consultative et l’API entrante pour faire surface [security concerns] aux mainteneurs », a déclaré Durbin. ®

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *