Python : ce bug oublié qui menace 350 000 projets

Imaginez découvrir qu’un problème de sécurité, identifié il y a plus de quinze ans, n’a jamais été réellement corrigé. Pire encore, imaginez que ce bug se soit discrètement propagé dans des centaines de milliers de projets open-source, y compris ceux qui alimentent les intelligences artificielles les plus modernes. Ce n’est pas le scénario d’un thriller de cybersécurité, mais la réalité de la vulnérabilité CVE-2007-4559 qui secoue aujourd’hui l’écosystème Python.

Cette faille, aussi ancienne que le premier iPhone, a été redécouverte par les chercheurs de la société de cybersécurité Trellix, révélant une négligence aux conséquences potentiellement massives. Nous allons décortiquer cette affaire pour comprendre la nature du bug, l’ampleur de sa propagation et ce qu’elle nous apprend sur la sécurité de l’écosystème open-source.

CVE-2007-4559 : le fantôme du code Python

Pour bien saisir l’enjeu, il faut d’abord comprendre la nature de cette vulnérabilité. Elle n’est pas complexe à exploiter, ce qui la rend d’autant plus préoccupante.

Qu’est-ce que ce bug exactement ?

La faille, référencée sous le nom de CVE-2007-4559, est ce que l’on appelle une vulnérabilité de « path traversal » (ou traversée de répertoire). Elle se cache dans une bibliothèque standard de Python nommée `tarfile`, utilisée pour manipuler les archives de fichiers (similaires aux fichiers .zip ou .rar). Plus précisément, les fonctions `extract()` et `extractall()` sont en cause.

➡️ Pour faire simple, lorsqu’un développeur utilise ce code pour décompresser une archive, un pirate peut créer une archive malveillante. Au lieu de se décompresser dans le dossier prévu, les fichiers qu’elle contient peuvent « remonter » l’arborescence des dossiers pour aller s’écrire n’importe où sur le système de fichiers, écrasant potentiellement des fichiers sensibles ou installant du code malveillant.

Une faille connue, mais jamais corrigée

Le plus surprenant dans cette histoire est que ce bug n’est pas nouveau. Il a été signalé pour la première fois en août 2007. Cependant, à l’époque, la seule « correction » apportée a été une mise à jour de la documentation officielle de Python.

Le message était clair, mais insuffisant : il avertissait simplement les développeurs qu’il « peut être dangereux d’extraire les archives de sources inconnues ».

Aucun correctif de code n’a été déployé, laissant la porte ouverte. Quinze ans plus tard, le chercheur Kasimir Schulz de Trellix est retombé sur cette faille presque par hasard. En tirant sur ce fil, son équipe a découvert que le problème était loin d’être anecdotique.

L’ampleur du problème : une contagion silencieuse

Si un bug isolé est un problème, un bug répandu à travers un écosystème est une crise. L’analyse de Trellix a révélé une propagation bien plus large que quiconque aurait pu l’imaginer.

De quelques lignes de code à 350 000 dépôts

Avec l’aide de GitHub, les chercheurs ont identifié près de 590 000 projets open-source utilisant la fameuse bibliothèque `tarfile`. En analysant un échantillon représentatif de ces projets, ils ont découvert qu’un taux alarmant de 61% d’entre eux utilisaient les fonctions vulnérables sans aucune précaution.

En extrapolant ce chiffre, on arrive à une conclusion vertigineuse : plus de 350 000 dépôts de code sur GitHub seraient directement affectés. Ces projets couvrent un large éventail d’industries, mais les secteurs les plus touchés sont le développement web, les outils pour développeurs et, surtout, le machine learning.

Les outils de Machine Learning comme vecteurs de propagation

C’est là que le problème prend une dimension très moderne. Des outils d’assistance au code basés sur l’IA, comme GitHub Copilot, sont entraînés sur des millions de lignes de code issues de dépôts open-source. Si une grande partie de ce code est vulnérable, l’IA apprend et peut proposer ces mêmes extraits de code non sécurisés à des développeurs qui lui font confiance.

Le bug ne se propage donc plus seulement par copier-coller humain, mais aussi via des suggestions automatisées. Un développeur, pensant gagner du temps, peut ainsi intégrer la faille dans un nouveau projet sans même en avoir conscience, perpétuant le cycle.

Concrètement, quels sont les risques ?

Savoir qu’une faille existe est une chose, mais comprendre comment elle peut être exploitée est essentiel pour mesurer le danger réel.

Comment un attaquant peut-il exploiter la faille ?

Le scénario est relativement simple. Un attaquant crée une archive `.tar` spécialement conçue. Il la transmet ensuite à sa victime, par exemple en la téléchargeant sur une plateforme où elle sera traitée par une application vulnérable.

Lorsque l’application utilise la fonction `tarfile.extractall()` pour décompresser le fichier, le piège se referme : le code malveillant est écrit sur le système, permettant à l’attaquant d’exécuter des commandes à distance.

Les chercheurs de Trellix ont démontré que l’exploitation était possible sur différents systèmes, parvenant notamment à exécuter du code sur l’environnement de développement Spyder IDE sous Windows, et sur l’outil de gestion d’infrastructure Polemarch sous Linux.

Des correctifs en cours, mais un travail de titan

Heureusement, Trellix ne s’est pas contenté de sonner l’alarme. L’entreprise a entrepris de corriger elle-même le problème. Des correctifs ont déjà été créés pour plus de 11 000 projets et sont en cours de soumission via des « pull requests » sur GitHub.

L’objectif est d’en proposer pour plus de 70 000 projets.

Cependant, le défi est immense. Chaque correctif doit être examiné et validé par le ou les mainteneurs de chaque projet, dont beaucoup sont des bénévoles. Ce processus prendra des mois, voire des années, et certains projets abandonnés ne seront probablement jamais mis à jour.

Au-delà du bug : la sécurité de l’open-source en question

Cette affaire n’est pas qu’une simple anecdote technique. Elle soulève des questions essentielles sur la manière dont nous construisons et sécurisons les logiciels aujourd’hui.

Un écho à la faille Log4Shell

Cette situation rappelle amèrement la crise de la vulnérabilité Log4Shell qui a secoué le monde de la tech fin 2021. Dans les deux cas, une faille critique dans une bibliothèque open-source fondamentale, utilisée par des millions d’applications, est passée sous les radars pendant des années. Elle met en lumière la fragilité de notre chaîne d’approvisionnement logicielle.

Vers une meilleure culture de la sécurité ?

Alors que faire ? Des initiatives voient le jour pour tenter de résoudre ce problème systémique. Des concepts comme le SBOM (Software Bill of Materials), qui agit comme une liste d’ingrédients pour un logiciel, permettent de savoir exactement quels composants open-source sont utilisés.

D’autres, comme les niveaux SLSA (Supply-Chain Levels for Software Artifacts), visent à établir des standards de sécurité pour la production de logiciels.

Ces efforts, portés par des organisations comme l’Open Source Security Foundation, sont essentiels. Ils visent à allouer des ressources pour auditer et sécuriser les projets les plus critiques, souvent maintenus par une poignée de développeurs non rémunérés.

La redécouverte de la faille CVE-2007-4559 est un puissant rappel à l’ordre. Elle nous montre que la sécurité n’est pas un acquis et que même les fondations de notre écosystème numérique peuvent comporter des fissures. Ce n’est pas seulement un problème pour les développeurs Python, mais pour toute l’industrie qui dépend massivement de la collaboration et de la confiance inhérentes à l’open-source.

C’est peut-être le coup de semonce dont nous avions besoin pour enfin traiter la sécurité de la chaîne d’approvisionnement logicielle avec le sérieux qu’elle mérite.

Et vous, comment sécurisez-vous les dépendances open-source dans vos projets ?

Simone

Simone, rédactrice principale du blog, est une passionnée de l’intelligence artificielle. Originaire de la Silicon Valley, elle est dévouée à partager sa passion pour l’IA à travers ses articles. Sa conviction en l’innovation et son optimisme sur l’impact positif de l’IA l’animent dans sa mission de sensibilisation.