versions correctives du système de contrôle de source distribué Git 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3, 2.18.2, 2.17.3, 2.16.6, 2.15.4 et 2.14.62.24.1 .XNUMX, qui corrige des vulnérabilités permettant à un attaquant de réécrire des chemins arbitraires dans le système de fichiers, d'organiser l'exécution de code à distance ou d'écraser des fichiers dans le répertoire « .git/ ». La plupart des problèmes identifiés par les employés
Le Centre de réponse aux incidents de sécurité de Microsoft indique que cinq des huit vulnérabilités sont spécifiques à une plateforme. Windows.
- - commande de streaming « feature export-marks=path » écrire des étiquettes dans des répertoires arbitraires, qui peuvent être utilisées pour écraser des chemins arbitraires dans le système de fichiers lors de l'exécution d'une opération "git fast-import" avec des données d'entrée non vérifiées.
- - échappement incorrect des arguments de ligne de commande à l'exécution à distance du code de l'attaquant lors du clonage récursif à l'aide de l'URL ssh://. En particulier, les arguments d'échappement se terminant par une barre oblique inverse (par exemple, « test \ ») étaient mal gérés. Dans ce cas, lors du cadrage d'un argument avec des guillemets doubles, le dernier guillemet était échappé, ce qui permettait d'organiser la substitution de vos options sur la ligne de commande.
- — lors du clonage récursif de sous-modules (« clone --recurse-submodules ») dans l'environnement Windows sous certaines conditions déclencher deux fois l'utilisation du même répertoire git (.git, git~1, git~2 et git~N sont reconnus comme un seul répertoire dans NTFS, mais cette situation n'a été testée que pour git~1), ce qui pourrait être utilisé pour organiser écrire dans le répertoire ". git". Pour organiser l'exécution de son code, un attaquant peut par exemple substituer son script via le gestionnaire de post-checkout présent dans le fichier .git/config.
- — Gestionnaire des noms de lettres de lecteur dans les chemins Windows Lors de la traduction de chemins tels que « C:\ », le système était conçu uniquement pour remplacer les identificateurs latins à une seule lettre, sans tenir compte de la possibilité de créer des disques virtuels désignés par « subst letter:path ». Ces chemins étaient traités non pas comme des chemins absolus, mais comme des chemins relatifs, ce qui permettait, lors du clonage d'un dépôt malveillant, d'écrire dans un répertoire arbitraire en dehors de l'arborescence du répertoire de travail (par exemple, en utilisant des chiffres ou des caractères Unicode dans le nom du disque : « 1:\what\the\hex.txt » ou « ä:\tschibät.sch »).
- - lors du travail sur la plateforme Windows en utilisant des flux de données alternatifs dans NTFS, créés en ajoutant l'indicateur « :nom-flux:type-flux » au nom du fichier, écraser les fichiers du répertoire ".git/" lors du clonage d'un référentiel malveillant. Par exemple, le nom « .git::$INDEX_ALLOCATION » dans NTFS a été traité comme un lien valide vers le répertoire « .git ».
- — lors de l'utilisation de Git dans un environnement WSL (Windows Sous-système pour Linux) lors de l'accès au répertoire de travail protection contre la manipulation de noms dans NTFS (des attaques via la traduction de noms FAT étaient possibles, par exemple, « .git » était accessible via le répertoire « git~1 »).
- -
entrées dans le répertoire ".git/" sur la plateforme Windows lors du clonage de dépôts malveillants contenant des fichiers dont le nom comporte une barre oblique inverse (par exemple « a\b »), ce qui est autorisé sous Unix/Linuxmais est perçu comme faisant partie du chemin vers Windows. - — une vérification insuffisante des noms de sous-modules pourrait être utilisée pour organiser des attaques ciblées, qui, si elles étaient clonées de manière récursive, pourraient potentiellement pour exécuter le code de l'attaquant. Git n'a pas empêché la création d'un répertoire de sous-module dans le répertoire d'un autre sous-module, ce qui dans la plupart des cas ne ferait que prêter à confusion, mais n'a pas potentiellement empêché le contenu d'un autre module d'être écrasé lors du processus de clonage récursif (par exemple, les répertoires du sous-module "hippo" et "hippo/hooks" sont placés sous la forme " .git/modules/hippo/" et ".git/modules/hippo/hooks/", et le répertoire hooks dans hippo peut être utilisé séparément pour héberger des hooks déclenchés.
Пользователям Windows Il est recommandé de mettre à jour votre version de Git de toute urgence et de vous abstenir de cloner des dépôts non fiables jusqu'à la fin de la mise à jour. Si aucune mise à jour urgente de Git n'est disponible, afin de réduire les risques d'attaque, il est recommandé de ne pas exécuter les commandes « git clone --recurse-submodules » et « git submodule update » avec des dépôts non fiables, de ne pas utiliser « git fast-import » avec des flux d'entrée non fiables et de ne pas cloner de dépôts sur des partitions NTFS.
Pour plus de sécurité, les nouvelles versions interdisent également l'utilisation de constructions de la forme "submodule.{name}.update=!command" dans .gitmodules. Pour les distributions, vous pouvez suivre la publication des mises à jour des packages sur les pages ,, , , , , , .
Source: opennet.ru
