GitHub a promis de cesser d’envoyer des avis sur une vulnérabilité signalée dans Loguru, un package de journalisation Python populaire, qui s’est ensuite avéré invalide.

La semaine dernière, la plate-forme DevOps a commencé à informer des dizaines de milliers d’utilisateurs de ce qui était considéré comme une vulnérabilité critique d’exécution de code à distance (RCE) dans Loguru, désignée comme CVE-2022-0329 et ayant reçu une note critique de 9,8/10.

Cependant, il est apparu depuis que le problème signalé n’est pas une vulnérabilité valide après tout.

L’histoire a commencé lorsqu’un chercheur signalé chargement de données non fiable par Loguru pickle.load fonction – qui sérialise et désérialise des objets Python arbitraires – conduisant à l’exécution de code arbitraire. Il a suggéré que le problème présentait des similitudes avec le célèbre exploit Log4Shell.

Cependant, le responsable a contesté cela au motif que la méthode incriminée ne faisait pas partie de l’API publique Loguru et que Pickle n’était utilisé que pour sérialiser des objets déjà chargés dans le code – ce qui signifie qu’il n’y avait un problème que si les données chargées ne ne proviennent pas d’une source fiable.

« L’utilisateur qui reçoit des données non fiables devrait être responsable de les nettoyer avant de les traiter. Nous ne pouvons pas nous attendre à ce que ce travail soit effectué par la bibliothèque tierce, sinon il pourrait y avoir une infinité de façons d’exécuter du code arbitraire », ont-ils déclaré.

« Cela n’a pas grand-chose à voir avec le module de cornichon. Loguru ne récupère pas et n’exécute pas de code arbitraire par lui-même.

Cependant, après une longue discussion, le responsable a été contraint d’agir. Un CVE a été émis et a trouvé son chemin vers GitHub, qui a alors commencé à envoyer des alertes automatiques via son service Dependabot.

Offrant de plus amples informations, Justin Hutchings, directeur de la gestion des produits chez GitHub, a déclaré La gorgée quotidienne: « CVE-2022-0329 a été émis par huntr.dev avec une gravité de 3,8 (faible).

«La base de données nationale sur les vulnérabilités (NVD) a mis à niveau le score de gravité à 9,8 (critique) lors de sa publication, et nous l’avons ensuite republié dans notre base de données consultative et avons commencé à envoyer des alertes.

« Il s’agit d’une pratique standard chez tous les principaux fournisseurs de sécurité, mais dans ce cas, la reclassification de cette vulnérabilité par le NVD en tant que vulnérabilité critique a provoqué une alarme indue. »

Crédibilité imméritée

Maintenant, cependant, GitHub a examiné le problème et dit qu’il cessera d’envoyer les avertissements.

« Nous n’avons actuellement aucun moyen de retirer les alertes Dependabot que nous avons déjà envoyées, mais j’ai demandé à l’équipe d’examiner la fonctionnalité pour le faire à l’avenir », a déclaré Hutchings.

« Je leur ai également demandé d’envisager d’ajouter un moyen clair d’afficher les CVE dans la base de données consultative GitHub sur lesquelles nous avons choisi de ne pas alerter (même s’ils n’ont pas été retirés de la base de données nationale sur les vulnérabilités). »

Le problème met en évidence à quel point il peut être facile d’accorder une crédibilité non méritée à un rapport faux ou contesté, et Hutchings dit qu’il prévoit d’impliquer le GitHub Security Lab dans la recherche de solutions.

« J’aimerais que nous (GitHub) tirions les leçons de ce qui précède et améliorons nos fonctionnalités et processus liés à la sécurité pour aider davantage lorsqu’un responsable reçoit un rapport de sécurité », dit-il.