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
Microsoft Security Response Center, cinq des huit vulnérabilités sont spécifiques à la 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.
- — le gestionnaire des noms de lecteurs de lettres dans les chemins Windows lors de la traduction de chemins tels que « C:\ » a été conçu uniquement pour remplacer les identifiants latins à une seule lettre, mais n'a pas pris en compte la possibilité de créer des lecteurs virtuels attribués via « subst letter:path » . De tels chemins n'étaient pas traités comme des chemins absolus, mais comme des chemins relatifs, ce qui permettait, lors du clonage d'un référentiel malveillant, d'organiser un enregistrement dans un répertoire arbitraire en dehors de l'arborescence des répertoires de travail (par exemple, lors de l'utilisation de nombres ou de caractères Unicode dans le disque nom - "1:\what\the\ hex.txt" ou "ä:\tschibät.sch").
- — lorsque l'on travaille sur la plateforme Windows, l'utilisation de flux de données alternatifs en NTFS, créés en ajoutant l'attribut « :stream-name:stream-type » 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 Subsystem for 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 »).
- -
écrit dans le répertoire « .git/ » sur la plate-forme Windows lors du clonage de référentiels malveillants contenant des fichiers avec une barre oblique inverse dans le nom (par exemple, « a\b »), ce qui est acceptable sous Unix/Linux, mais est accepté dans le cadre de le chemin sous 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.
Il est conseillé aux utilisateurs Windows de mettre immédiatement à jour leur version de Git et de s'abstenir de cloner des référentiels non vérifiés jusqu'à la mise à jour. S'il n'est pas encore possible de mettre à jour en urgence la version de Git, alors pour réduire le risque d'attaque, il est recommandé de ne pas exécuter « git clone —recurse-submodules » et « git submodule update » avec des référentiels non vérifiés, de ne pas utiliser « git fast-import » avec des flux d’entrée non contrôlés, et de ne pas cloner les référentiels 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