L’équipe du « Advanced Research Center » de Trellix a corrigé plus de 61 895 projets open source sensibles à un faille Python vieille de… 15 ans !
Grâce à GitHub, les développeurs et les membres de la communauté sont en mesure de pousser du code vers des projets ou des dépôts sur la plateforme via un processus appelé « pull request ». Une fois la demande ouverte, les responsables du projet examinent le code suggéré, demandent une collaboration ou une clarification si nécessaire, et acceptent le nouveau code. Dans ce cas, le code poussé par « pull request » a fourni des correctifs spécifiques à chacun des projets GitHub vulnérables.
Pour définir un processus d’automatisation des correctifs, l’équipe Trellix s’est inspirée de la conférence DEFCON 2022 de Jonathan Leitschuh sur la correction des vulnérabilités à grande échelle. L’équipe Trellix chargée des vulnérabilités a pu automatiser la plupart des processus, à l’exception du contrôle de la qualité et a divisé le processus en deux étapes : D’abord la phase de correction puis la phase de demande de retrait.
Douglas McKee, Principal Engineer & Director of Vulnerability Research au Advanced Research Center, nous les explique :
- Phase de correction « Après avoir reçu une liste de dépôts et de fichiers contenant le mot clé « import tarfile », notre équipe a pu dresser une liste unique de dépôts à analyser. Une fois la liste fournie, nous avons cloné et analysé chaque dépôt à l’aide de Creosote, un outil gratuit que nous avons créé pour permettre aux développeurs de vérifier si leurs applications sont vulnérables, afin de déterminer quels dépôts devaient être corrigés. S’il a été déterminé qu’un référentiel contenait la vulnérabilité, nous avons corrigé le fichier et créé un patch diff local contenant le fichier corrigé afin que les utilisateurs puissent facilement comparer les deux fichiers, le fichier original et certaines métadonnées sur le référentiel. Le référentiel est ensuite supprimé pour conserver de l’espace. »
- Phase de demande de mise à jour
« Une fois les correctifs prêts à être mis en ligne, nous avons passé en revue la liste des différences de correctifs locaux et, pour chaque dépôt, nous avons procédé comme suit : nous avons créé un fork du dépôt sur GitHub, cloné le fork, puis remplacé le fichier original par le fichier corrigé si le fichier original n’avait pas été modifié. Nous avons vérifié que le fichier original n’avait pas été modifié entre le clone original et le moment où nous avons créé notre fork pour nous assurer que nous n’avons pas écrasé de nouvelles modifications du fichier pendant cette période. Nous avons ensuite validé les changements dans le référentiel et créé une demande de transfert de notre référentiel bifurqué vers le référentiel d’origine avec un message détaillant qui nous étions et pourquoi nous faisions cette demande de transfert. À ce stade, c’était maintenant au propriétaire du dépôt d’accepter ou de rejeter nos changements.«
Pour le chercheur, les personnes souhaitant effectuer ce type de travail ne devraient pas négliger l’importance de gérer les serveurs sur lesquels le processus automatisé est exécuté et doivent garder un œil sur le retour d’information quant aux référentiels patchés. “La surveillance étroite de ces éléments nous a permis de répondre rapidement aux questions des destinataires des demandes de retrait et de résoudre rapidement les problèmes de serveur réseau”, conclut Douglas McKee.
Hélène Saire
