Le 29 mai dernier, gitster le mainteneur du projet Git a annoncé sur la liste de diffusion du projet la publication de la version v2.17.1 de Git afin de corriger une faille de sécurité sévère nommée CVE-2018-11235.
Des patchs correctifs ont également été publiés via les tags v2.13.7, v2.14.4, v2.15.2 et v2.16.4 sur les branches en maintenance.
Que fait cette vulnérabilité ?
Cette vulnérabilité n’affecte que les dépôts contenant des sous-modules et exécutant un clone récursif des sous-modules (git clone –recurse-submodules). Elle consiste en l’exécution du hook post-checkout d’un sous module malicieux.
Normalement les scripts de hooks ne font pas partie des dépôts Git. Ils sont générés par Git lors du clone et non lus depuis le serveur. Dans ce cas de figure, des hooks définis dans un sous-module construit avec des chemins d’accès appropriés (via ../ par exemple ou un lien symbolique) peuvent être lus et exécutés dès la fin du clone récursif via le hook post-checkout (lequel s’exécute dès qu’un fichier versionné est placé dans l’espace de travail, donc dans ce cas de figure lors du checkout du sous module vérolé par le dépôt parent).
Que fait le patch ?
Il interdit tout simplement la configuration d’un sous module (fichier .gitmodules) avec un chemin d’accès contenant un segment ../.
Impact sur l’écosystème ?
Git n’est pas utilisé seulement par les développeurs comme SCM, il est également utilisé comme vecteur de déploiement dans pas mal de cas ce qui augmente considérablement l’impact de cette faille.
Le gestionnaire de paquets JavaScript npm ne limite pas les dépendances à des paquets construits via npm et hébergés sur le registre. On peut tout à fait définir une dépendance comme étant un dépôt Git quelconque. Dans ce cas de figure le client npm délègue au Git installé localement l’installation (le clone donc) du dépôt. L’équipe npm a donc publié sur son blog une recommandation visant à contrôler sa version locale de Git et à la mettre à jour si besoin.
De même l’équipe Microsoft gérant le Visual Studio Team Services (VSTS) bloque désormais tous les dépôts contenant une telle configuration afin de ne pas servir de vecteur d’attaque. Edward Thomson a publié un billet sur le blog DevOps de Microsoft à ce sujet.
Les autres hébergeurs classiques de dépôts comme GitHub et GitLab ont également pris des mesures en ce sens, ainsi un développeur souhaitant pousser un dépôt démontrant la vulnérabilité n’a pas pu et indique seulement comment générer un tel dépôt.
