Mise à jour de Git corrigeant 8 vulnérabilités

Publié Les mises à jour correctives du système de gestion distribué de versions 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.6 corrigent des vulnérabilités permettant à un attaquant de réécrire des chemins arbitraires dans le système de fichiers, d'organiser l'exécution distante de code ou de réécrire des fichiers dans le répertoire « .git/ ». La plupart des problèmes ont été identifiés par des employés
du Microsoft Security Response Center, cinq des huit vulnérabilités sont spécifiques à la plateforme Windows.

  • CVE-2019-1348 — commande de flux « feature export-marks=path »d'installer écrit des marqueurs dans des répertoires arbitraires, ce qui peut être utilisé pour réécrire des chemins arbitraires dans le FS lors de l'exécution de l'opération « git fast-import » avec des entrées non vérifiées.
  • CVE-2019-1350 — échappement incorrect des arguments de la ligne de commande pouvait entraîner l'exécution à distance du code de l'attaquant lors d'un clonage récursif utilisant l'URL ssh://. En particulier, l'échappement des arguments se terminant par un antislash (par exemple, « test \ ») n'était pas correctement géré. Dans ce cas, lors de l'encapsulation de l'argument entre guillemets, le dernier guillemet était échappé, ce qui permettait d'insérer ses propres options dans la ligne de commande.
  • CVE-2019-1349 — lors du clonage récursif de sous-modules (« clone —recurse-submodules ») dans un environnement Windows sous certaines conditions il était possible d'initier l'utilisation d'un même répertoire git deux fois (.git, git~1, git~2 et git~N en NTFS étant reconnus comme un seul répertoire, mais cette situation n'était vérifiée que pour git~1), ce qui pourrait être utilisé pour organiser l'écriture dans le répertoire « .git ». Pour exécuter son propre code, un attaquant pouvait, par exemple, insérer son script via le gestionnaire post-checkout dans le fichier .git/config.
  • CVE-2019-1351 — le gestionnaire des noms de lecteurs dans les chemins Windows lors de la traduction de chemins de type « C:\ » était conçu uniquement pour remplacer des identifiants alphabetiques à une lettre, sans tenir compte de la possibilité de créer des disques virtuels assignés via « subst lettre: chemin ». De tels chemins étaient traités non pas comme des chemins absolus, mais comme des chemins relatifs, permettant, lors du clonage d'un dépôt malveillant, d'organiser l'écriture dans un répertoire arbitraire en dehors de l'arborescence 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 »).
  • CVE-2019-1352 Lors de l'utilisation de la plateforme Windows, l'application de flux de données alternatifs dans NTFS, créés par l'ajout de l'attribut «:stream-name:stream-type» au nom de fichier, permettait de réécrire des fichiers dans le répertoire «.git/» lors du clonage d'un dépôt malveillant. Par exemple, le nom «.git::$INDEX_ALLOCATION» dans NTFS était traité comme un lien valide vers le répertoire «.git».
  • CVE-2019-1353 — lors de l'utilisation de Git dans un environnement WSL (Windows Subsystem for Linux) en accédant au répertoire de travail la protection contre la manipulation des noms dans NTFS (des attaques par translation de noms étaient possibles, comme accéder à «.git» à travers le répertoire «git~1»). n'était pas appliquée
  • CVE-2019-1354 —
    la possibilité l'écriture dans le répertoire «.git/» sur la plateforme Windows lors du clonage de dépôts malveillants contenant des fichiers avec des barres obliques inverses dans le nom (par exemple, «a\b»), ce qui est permis dans Unix/Linux, mais est considéré comme faisant partie du chemin dans Windows.
  • CVE-2019-1387 — une vérification insuffisante des noms de sous-modules pouvait être utilisée pour orchestrer des attaques ciblées, qui lors du clonage récursif pouvaient potentiellement entraîner l'exécution de code de l'attaquant. Git ne prohibait pas la création d'un répertoire de sous-module dans un répertoire d'un autre sous-module, ce qui dans la plupart des cas peut simplement causer de la confusion, mais n'exclut pas potentiellement la réécriture du contenu d'un autre module lors du processus de clonage récursif (par exemple, les répertoires des sous-modules «hippo» et «hippo/hooks» sont placés respectivement dans «.git/modules/hippo/» et «.git/modules/hippo/hooks/», et le répertoire hooks dans hippo peut être utilisé séparément pour placer des gestionnaires exécutables.

Il est recommandé aux utilisateurs de Windows de mettre à jour urgent la version de Git, et avant la mise à jour, d'éviter de cloner des dépôts non vérifiés. Si la mise à jour urgente de Git n'est pas possible, il est conseillé pour réduire le risque d'attaque de ne pas exécuter «git clone --recurse-submodules» et «git submodule update» avec des dépôts non vérifiés, de ne pas utiliser «git fast-import» avec des flux d'entrée non vérifiés et de ne pas cloner des dépôts dans des partitions basées sur NTFS.

Pour une protection supplémentaire dans les nouvelles versions, l'utilisation de constructions sous la forme «submodule.{name}.update=!command» dans .gitmodules est également interdite. Pour les distributions, les mises à jour des paquets peuvent être suivies sur les pages Debian,Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, ALT, FreeBSD.

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster