Une étude menée par l’entreprise de cybersécurité Snyk a révélé que des milliers de projets pourraient être affectés par une sérieuse vulnérabilité, une vulnérabilité tellement triviale que nous vous conseillons de mettre un coussin sur votre bureau avant de continuer à lire cet article (en cas de blessure involontaire à la tête).
Comme vous pouvez le deviner à partir de son nom plutôt original, Zip Slip, cette vulnérabilité concerne les fichiers archives Zip.
En un mot, les cybercriminels peuvent créer des archives Zip pour lancer des attaques par traversée de chemin afin d’écraser des fichiers importants sur les systèmes affectés, soit en les détruisant, soit en les remplaçant par d’autres fichiers malveillants.
Les cybercriminels peuvent utiliser cette capacité pour cibler des fichiers qu’ils peuvent lancer à distance, tels que des parties d’un site web, ou des fichiers susceptibles d’être exécutés par un ordinateur ou un utilisateur, comme des applications populaires ou des fichiers système.
Zip Slip n’est pas lié à un problème avec le format de fichier Zip, il s’agit plutôt d’une mauvaise programmation qui a été répétée encore et encore, et ce dans beaucoup de projets différents :
La vulnérabilité a été trouvée dans plusieurs écosystèmes, y compris JavaScript, Ruby, .NET et Go, mais s’est particulièrement répandue dans Java, où il n’existe pas de bibliothèque centrale offrant un haut niveau de traitement des fichiers archives (par exemple zip). L’absence d’une telle bibliothèque a permis à des fragments de code vulnérables d’être conçus manuellement et partagés entre des communautés de développeurs telles que StackOverflow.
… [elle] peut affecter de nombreux formats archives, y compris tar, jar, war, cpio, apk, rar et 7z.
Malheureusement, cette maladresse au niveau du codage a été commise dans plusieurs bibliothèques de logiciels, dans plusieurs langages, ce qui a pour effet de la propager massivement, tout en la rendant plus difficile à corriger.
Les bibliothèques logiciels sont des morceaux de code conçus pour être inclus dans d’autres projets logiciels. Ainsi, non seulement les bibliothèques vulnérables doivent être corrigées, mais le logiciel qui utilise ces bibliothèques doit l’être également. Et, bien sûr, un patch n’est efficace que s’il est véritablement installé !
Snyk détient des listes de projets et de bibliothèques affectés sur GitHub.
C’est parti pour un nouveau BWAIN
Le bug a été divulgué de manière responsable, ce qui signifie que les projets connus pour être vulnérables ont été prévenus il y a quelques mois, leur donnant ainsi du temps pour créer et déployer des correctifs, et ce avant que des potentiels cybercriminels n’en soient informés.
Ce décalage, bien pratique, entre la découverte et la divulgation, et rendu possible par ce type de comportement responsable, met les services marketing et communication dans un état d’excitation difficile à contenir. En effet, cela leur donne des mois, oui des mois, pour transformer les compétences de chasseurs de bugs de leurs experts en une réelle campagne de communication tape-à-l’œil, en utilisant ce que l’on appelle un BWAIN (a Bug With An Interesting Name).
Ainsi, le voilà, avec toute cette gloire inutile qui l’accompagne : le logo fantaisiste, l’article de blog, … l’un autre article de blog, la vidéo, cet article utile sur GitHub, le livre blanc et la promotion du livre.
OK, j’ai menti au sujet de la promotion du livre, désolé !
Comme fonctionne-t-il ?
Un cybercriminel commence par trouver un système qu’il pense être vulnérable, par exemple un site web ou une application en ligne qui lui permet de télécharger des fichiers archives zip.
Ensuite, il créé un fichier zip contenant des versions malveillantes des fichiers qu’il veut remplacer. Il devra être plutôt confiant concernant la présence des fichiers ciblés sur le système, et l’endroit où ils se trouvent exactement sur ce dernier.
Le format de fichier Zip permet aux fichiers d’être stockés avec des chemins qui spécifient où ces fichiers devront être placés lorsque l’archive sera décompressée. En fait, les chemins peuvent être des chemins relatifs tels que ../ (dans le cas de systèmes d’exploitation de type Unix, tels que Linux ou macOS, “dot-dot-slash” signifie “le répertoire suivant en amont du répertoire de travail en cours d’utilisation”).
Si un cybercriminel connaît l’emplacement du fichier cible et du répertoire de travail de l’application qu’il exploite, il peut déterminer le chemin relatif correcte pour décompresser un fichier malveillant directement en amont d’un fichier cible.
Alternativement, il peut tenter de cibler un fichier même s’il ne connait pas l’emplacement du répertoire de travail, et ce simplement en ajoutant toute une série de “dot-dot-slash” supplémentaires au niveau du chemin.
Pourquoi ? Parce que vous ne pouvez pas parcourir le système de fichiers au-delà de la racine : /.
Ainsi, au niveau d’un système de fichiers qui comporte une arborescence se composant de six répertoires uniquement, ces chemins signifient tous la même chose, et ce de n’importe quel endroit au sein du système de fichiers :
../[five or more dot-dot-slashes]etc/passwd ../../../../../../etc/passwd /etc/passwd.
Maintenant, si vous êtes un développeur de code, j’espère que vous avez bien placé ce coussin, mentionné plus haut, sur votre bureau. Si vous ne l’avez pas encore mis, je m’attends à ce que vous ayez mal à la tête.
Bien sûr vous vous dites, dans ces rares moments de lucidité entre chaque impact de votre tête sur le bureau, que les archives Zip peuvent décompresser les fichiers à des endroits arbitraires dans le système de fichiers en théorie de toutes façons … mais vous n’avez pas à les laisser faire!
Les chemins de fichier dans les archives zip sont des contenus fournis par l’utilisateur et comme tout programmeur qui se respecte vous le dira, vous ne pouvez pas faire confiance au contenu fourni par l’utilisateur. Peu importe que ce soit le contenu des fichiers eux-mêmes ou des métadonnées, tels que les chemins de fichiers.
Ou, comme l’a déclaré Snyk :
La vulnérabilité existe lorsque le code d’extraction omet la validation au niveau des chemins de fichiers dans l’archive.
On peut également se demander pourquoi ces applications, mal codées, s’exécutent en tant qu’utilisateurs autorisés à écraser des fichiers arbitraires, et pourquoi ils ne fonctionnent pas dans un contexte de type sandbox, comme une chroot “jail”, qui empêcherait l’accès à d’autres parties du système, et enfin pourquoi ces fichiers importants sont susceptibles d’être écrasés.
Quoi faire ?
Panique. Fuyons. C’est la fin de notre civilisation !
Non, pas vraiment, c’est juste un nouveau bug logiciel. Il a un beau logo, avec de bonnes prestations, il est intéressant, et pour certaines personnes il est sérieux, mais, comme toujours, corrigez-le et passez à autre chose.
Snyk a publié des listes de projets et de bibliothèques avec des vulnérabilités connues sur GitHub. Commencez par là et vérifiez si vous utilisez un logiciel vulnérable. Des mises à jour sont disponibles pour la plupart des éléments listés, donc ne tardez pas à patcher vos systèmes.
Si vous avez un logiciel qui gère ses propres décompressions, vous devriez le tester pour voir s’il est vulnérable. Le moment est peut-être opportun pour vérifier si une bibliothèque standard ne serait pas une meilleure option, si vos systèmes sont bien configurés avec une défense profonde, et enfin si vos applications fonctionnent conformément au principe du moindre privilège.
Billet inspiré de The Zip Slip vulnerability – what you need to know, sur Sophos nakedsecurity.
