Skip to main content

Écriture arbitraire de fichiers via l’extraction d’archives (Zip Slip) dans go-rpmutils

Écrit par

20 juillet 2020

0 minutes de lecture

Bienvenue dans le Profil mensuel des vulnérabilités de Snyk. Dans cette série, Snyk revient sur les vulnérabilités découvertes par notre équipe de recherche en sécurité. Chaque mois, nous choisissons une vulnérabilité marquante et racontons les coulisses de sa découverte, de son analyse et de sa divulgation. Nous mettons en lumière les chercheurs, les développeurs et les utilisateurs qui contribuent à repérer et à corriger les vulnérabilités dans l’ensemble de la communauté open source.

Ce mois-ci, nous nous penchons sur l’une des vulnérabilités de type Zip Slip identifiées par l’équipe de recherche en sécurité de Snyk dans des packages Golang.


Vulnérabilité : Écriture arbitraire de fichiers via l’extraction d’archives (Zip Slip) CVE attribué :CVE-2020-7667Analyste Snyk : George GkitsasDécouverte par : l’équipe de recherche de Snyk

Le 5 juin 2020, l’équipe de recherche de Snyk a publié les détails d’une vulnérabilité permettant l’écriture arbitraire de fichiers au moyen d’une archive zip malveillante. La vulnérabilité a été identifiée dans le package Golang go-rpmutils par des chercheurs de Snyk, dans le cadre d’une initiative plus vaste visant à repérer les vulnérabilités Zip Slip dans l’écosystème open source. George Gkitsas, analyste principal en sécurité, est le chercheur qui a initialement détecté la vulnérabilité dans le package rpmutils. La vulnérabilité a ensuite été signalée au responsable du package, rapidement corrigée, puis publiée dans la CVE ainsi que dans la Snyk Vulnerability Database, une fois la version corrigée du package disponible.

Avant d’entrer dans le détail de la recherche qui a permis de découvrir cette vulnérabilité, examinons rapidement la nature d’une vulnérabilité Zip Slip. Son exploitation consiste à tirer parti d’une traversée de répertoires au moyen d’une archive conçue à des fins malveillantes. Lorsque cette archive est extraite par une méthode vulnérable, des fichiers situés à des emplacements non prévus peuvent être écrasés. Un attaquant pourrait ainsi écraser des fichiers système, exécuter à distance des commandes malveillantes, voire obtenir un accès à distance au système. Pour en savoir plus sur les aspects techniques de la vulnérabilité Zip Slip et sur les moyens de la prévenir, consultez la fiche pratique Zip Slip.

En tant que membre de l’équipe de recherche de Snyk, George cherchait des motifs pouvant être repérés rapidement dans les dépôts afin d’identifier les packages potentiellement vulnérables. Dans le cadre de ses recherches, il a d’abord choisi de se concentrer sur l’écosystème Golang. L’équipe a sélectionné une soixantaine de packages pour cette première phase et les a analysés un par un afin de détecter d’éventuelles vulnérabilités. Plusieurs faux positifs ont été relevés, ce qui a permis à l’équipe d’affiner ses algorithmes. Au final, cinq vulnérabilités ont été découvertes. Trois d’entre elles, dont celle du package go-rpmutils, ont reçu un identifiant CVE et ont été publiées dans la Snyk Vulnerability Database. Snyk continue de collaborer avec les responsables des deux autres packages vulnérables afin qu’un correctif soit disponible avant la divulgation publique des vulnérabilités.

Éditeur de code sombre affichant du code Go qui ouvre un fichier et extrait une archive ZIP à l’aide de cpio.

Dans le cas de go-rpmutils, après avoir découvert la vulnérabilité et confirmé qu’elle pouvait être exploitée, George a tenté de contacter le responsable du package, une organisation appelée SAS Software. Il a d’abord envoyé un e-mail à l’adresse indiquée sur le profil de l’organisation dans le dépôt. Cette adresse n’était finalement pas la bonne pour ce type de signalement, mais la notification de George a rapidement été transmise à une personne chargée de traiter ces divulgations. Snyk a appris par la suite que SAS Software disposait d’une adresse e-mail dédiée aux signalements de vulnérabilités. De nombreux acteurs des communautés de la sécurité et du développement considèrent cette pratique comme exemplaire.

Quoi qu’il en soit, SAS Software s’est montré réactif tout au long du processus : l’équipe a répondu dans les heures qui ont suivi le signalement initial. George a collaboré avec les spécialistes de la sécurité afin de garantir une divulgation publique responsable de la vulnérabilité dès qu’un correctif serait disponible. L’équipe du fournisseur a rapidement proposé un correctif, que George a pu tester et dont il a confirmé qu’il corrigeait suffisamment la vulnérabilité. La vulnérabilité a finalement été publiée le 5 juin 2020, seulement six jours après le premier signalement au fournisseur.

Ce cas illustre parfaitement la coopération possible entre les chercheurs et les responsables de packages lorsque toutes les parties s’engagent à traiter les problèmes de sécurité de façon responsable et efficace. Ici, le responsable, SAS Software, s’est montré très réactif et a agi rapidement et de manière décisive pour résoudre le problème. Snyk et SAS Software ont collaboré afin de s’assurer que le correctif réglait pleinement le problème et que les détails de la vulnérabilité ne soient rendus publics qu’une fois le correctif disponible. Cette histoire nous rappelle notamment qu’il est utile de prévoir un canal dédié au signalement des vulnérabilités. Pensez également à le rendre facilement accessible en le publiant dans vos fichiers README et sur le profil de votre dépôt.

Snyk a pour objectif de vérifier la validité et l’exploitabilité des vulnérabilités, tout en fournissant aux responsables des divulgations responsables et des conseils détaillés pour les corriger. Pour en savoir plus sur cette vulnérabilité ou sur la façon de signaler une vulnérabilité que vous avez découverte dans un projet open source, consultez les liens ci-dessous.

Lancez-vous dans les challenges Capture The Flag

Apprenez à résoudre des challenges Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.