Vulnérabilité Git liée au retour chariot et à l’exécution de code à distance lors du clone

• Présentation d’une technique d’attaque exploitant des caractères de retour chariot dans un dépôt Git
• Cette vulnérabilité ouvre la possibilité d’une exécution de code à distance (RCE)
• Des commandes malveillantes peuvent être exécutées pendant un certain processus de git clone
• L’impact a été confirmé sur des environnements Linux et Windows
• Mise en avant des risques liés à une gestion insuffisamment sécurisée des dépôts Git

---

Caractères de retour chariot et vulnérabilité Git

• Il est possible de créer, à l’intérieur d’un dépôt Git, des noms de fichiers contenant des caractères de retour chariot (\r)
• Lorsqu’un dépôt contenant de tels noms de fichiers est dupliqué avec git clone, le processus d’interprétation des commandes peut entraîner l’exécution involontaire de commandes

Scénario d’exécution de code à distance (RCE)

• Un attaquant ajoute à un dépôt un fichier dont le nom contient un caractère de retour chariot, puis le commit
• Si un utilisateur exécute git clone sur ce dépôt, une mauvaise interprétation par le système de fichiers et les commandes Git peut provoquer l’exécution de code non souhaitée
• En particulier, il peut être possible d’amener l’exécution automatique de scripts de hook (par exemple du code dans le dossier .git/hooks)

Environnements affectés et réponse

• Le problème peut se produire dans Git sur divers systèmes d’exploitation, notamment Linux et Windows
• Il s’agit d’une menace de sécurité grave pour les développeurs et les entreprises qui administrent des dépôts Git ou clonent fréquemment des dépôts externes

Recommandations de sécurité

• Lors du clonage de dépôts Git externes non fiables, il est nécessaire d’utiliser la version la plus récente et de vérifier l’état de sécurité
• Il est recommandé de détecter les noms de fichiers contenant des caractères inhabituels dans le dépôt, en particulier des retours chariot, et de les examiner avant le clonage

[GN⁺]

Commentaire Hacker News

• Tout cela explique le phénomène suivant lors d’un clone de sous-module : la lecture se fait sous la forme path = ..., mais l’écriture enregistre vers un autre chemin qui ne se termine pas par ^M

  • Interrogation sur la façon dont l’« exécution de code à distance » mentionnée dans l’article se produit ici, et sur la gravité réelle du problème du point de vue de la sécurité

  • Le PoC n’a pas encore été publié, mais il est indiqué qu’il s’agit presque d’une simple adaptation de l’exploit CVE-2024-32002, et que les tests du commit correctif donnent aussi de gros indices

  • Citation de l’explication de CVE-2024-32002 : en manipulant de manière malveillante un dépôt contenant un sous-module et en exploitant un bug de Git, il est possible d’écrire des fichiers dans le répertoire .git/ au lieu du worktree du sous-module. Cela permet d’écrire un hook qui sera exécuté immédiatement pendant le clone, sans même laisser à l’utilisateur l’occasion d’inspecter le code réellement exécuté

  • En résumé, on peut injecter un hook Git malveillant dans le dépôt ; normalement, les hooks Git ne sont pas installés lors d’un git clone, mais cette attaque rend cela possible et ouvre la voie à l’exécution d’un hook pendant le processus de clone

  • Davantage d’informations sur le nouveau CVE sont disponibles ici

    • Lors de la lecture des valeurs de configuration, Git supprime les caractères CR et LF, mais lors de l’écriture il n’échappe pas le CR, ce qui entraîne une perte à la relecture
    • Si le chemin d’un sous-module se termine par un caractère CR, le chemin utilisé après suppression de ce caractère peut conduire à extraire le sous-module au mauvais endroit
    • S’il existe déjà un symlink entre ce chemin tronqué et le répertoire de hooks du sous-module, un attaquant peut obtenir une exécution de code arbitraire via un hook post-checkout
    • Avis selon lequel, au-delà de ce CVE, il vaut aussi la peine d’examiner les nombreuses autres vulnérabilités de Git

  • Mention de cette vérité simple mais gênante : dès qu’une écriture de fichier arbitraire est possible, on finit souvent par obtenir une RCE

• Mention des risques liés à l’écriture de fichiers de configuration avec un DSL ad hoc

  • Il n’existe souvent pas de spécification formelle de la grammaire, et la véritable référence du parsing se retrouve dispersée dans des implémentations maison de sérialisation/désérialisation

  • Si les deux divergent — par exemple si le parseur prend en charge une nouvelle syntaxe mais que le writer ne la reflète pas — les différences de parsing peuvent devenir explosives

  • La leçon : il faut un unique source of truth et une architecture où les parties qui en dépendent sont générées automatiquement à partir de celui-ci

  • Remarque que ce bug n’a toutefois rien à voir avec un problème de source of truth

    • Il s’agit d’une pure erreur de logique, qui aurait exactement pu se produire dans une bibliothèque système standard sous Unix si elle avait existé
    • Et si cela avait été dans une telle bibliothèque standard, l’impact aurait été bien plus grave ; ici, les dégâts restent relativement limités car ils touchent surtout des développeurs

  • Avis selon lequel le DSL utilisé ici (le format de fichier ini), bien qu’ad hoc, est très courant, familier et suffisamment structuré pour servir en pratique de spécification

    • L’essence du bug n’est pas le format lui-même, mais le parseur (ou lexer) codé à la main inséré au milieu, et ce type de code devrait désormais disparaître
    • Il reste peut-être encore quelques cas où du code hand-crafted très malin est nécessaire, mais jamais pour des formats d’échange de données ; si on a besoin de ini, autant prendre toml, sinon JSON, voire YAML, XML pour ceux qui aiment souffrir, et si l’on insiste sur un format binaire, protobufs
    • En conclusion, sauf si l’on écrit un langage de programmation, il ne faut pas écrire son parseur soi-même ; il faut absolument utiliser une bibliothèque

• Reproduction directe du problème, puis publication dans ce dépôt

  • Tentative immédiate de mise à jour vers la dernière version de Git ; ce n’est pas encore disponible sur Arch

  • Intention d’éviter les pull jusqu’au nouveau correctif, avec l’inquiétude que cela pose problème sur des dépôts populaires avec des pull automatiques, ce qui pourrait ralentir fortement les mises à jour

  • Question sur le fait que cette vulnérabilité ait été divulguée avant la publication du correctif

    • Autrefois, les articles expliquant comment exploiter une vulnérabilité apparaissaient surtout des mois après le patch ; aujourd’hui, souhait que chaque billet précise clairement, même brièvement, la différence entre « c’est réellement dangereux maintenant » et « c’est déjà corrigé, pas d’inquiétude »

• En voyant la mention d’une « simple adaptation » d’un exploit existant, interrogation sur l’absence d’usage de Landlock par Git (Landlock est une fonctionnalité de sécurité sandbox spécifique à Linux)

  • Suggestion qu’une opération git clone devrait avoir un accès en lecture seule au répertoire de configuration, des droits lecture/écriture sur le répertoire cible du clone, et une interdiction d’invoquer des sous-processus

  • Moquerie sur ce moment profond où chaque exploit finit toujours par lancer une calculatrice

  • Objection : interdire les sous-processus casserait tous les hooks Git comme post-checkout

    • Si l’on n’en a pas besoin, on pourrait exécuter Git dans un environnement de type conteneur avec seccomp, mais beaucoup de fonctionnalités seraient alors limitées

  • Et sans sous-processus, il serait aussi impossible d’utiliser Git via SSH

• Question pour savoir si Homebrew est lui-même concerné, c’est-à-dire s’il effectue des clones récursifs

  • Une possibilité est repérée dans ce code

  • Réponse selon laquelle l’objectif même de Homebrew est d’exécuter le code du dépôt, donc l’absence de clone récursif serait presque plus surprenante

    • Le point important est que la RCE n’a du sens que si les données clonées ne sont pas censées être exécutées, et ce cas reste rare

• Souvenir ravivé en voyant la célèbre citation de Jon Postel à propos de CR+LF

  • Partage de cet article et avis selon lequel ce conseil n’est peut-être plus adapté aujourd’hui comme il pouvait l’être en 2003
  • Comme l’expliquait alors Mark Crispin, beaucoup de gens comprennent mal le sujet ; cela est rapproché des remarques faites à la fin des années 1990 par Daniel J. Bernstein sur les problèmes créés par les conversions homme-machine (parsing/quoting)
  • Constat qu’après 25 ans, le problème d’un quoter qui n’escape pas CR se répète encore, et que même après correction, tout le whitespace n’est pas vérifié
  • D’après git blame, le code en cause a été écrit il y a 19 ans, ce qui coïncide avec le dixième anniversaire de la rétrospective de Bernstein
  • Partage de ressources supplémentaires : commit associé, article qmail, etc.
  • En fin de compte, mise en avant de cette réalité : les leçons péniblement apprises au XXe siècle doivent encore être réapprises au XXIe

• Pas encore de mise à jour vers Git 2.50.1 dans Homebrew, il faudra donc sans doute attendre encore un peu

  • Suggestion de passer par cette issue ou par brew install git --HEAD pour se mettre à jour

• Partage du fait que Homebrew et Debian Bookworm distribuent toujours des versions vulnérables

  • Information qu’il est désormais possible d’utiliser la version 2.50.1 dans Homebrew

• Réflexion sur ce que devrait faire un appel système qui énumère le contenu d’un répertoire lorsqu’un nom de fichier contient des caractères de contrôle ASCII (bytes) : nier l’existence de ce fichier, considérer cela comme une corruption du disque, ou faire autre chose

  • Mention que ces octets peuvent avoir une autre signification dans la locale courante ; comme sous Unix on ne suppose pas, contrairement à Windows, que tous les noms de fichiers sont en UTF-16, des situations inattendues peuvent survenir

  • Remarque simple : sur les systèmes de type Unix, les noms de fichiers (et d’autres chaînes) ne sont que des tableaux d’octets, ce qui explique ce problème