corrigerende releases van het gedistribueerde broncontrolesysteem 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 en 2.14.62.24.1 .XNUMX, waarmee kwetsbaarheden werden opgelost waardoor een aanvaller willekeurige paden in het bestandssysteem kon herschrijven, de uitvoering van externe code kon organiseren of bestanden in de map “.git/” kon overschrijven. De meeste problemen gesignaleerd door medewerkers
Microsoft Security Response Center zijn vijf van de acht kwetsbaarheden specifiek voor het Windows-platform.
- — streaming-opdracht “feature export-marks=path” schrijf labels naar willekeurige mappen, die gebruikt kunnen worden om willekeurige paden in het bestandssysteem te overschrijven bij het uitvoeren van een "git fast-import" operatie met ongecontroleerde invoergegevens.
- - onjuiste escape van opdrachtregelargumenten tot het op afstand uitvoeren van aanvallercode tijdens recursief klonen met behulp van de ssh:// URL. Met name ontsnappingsargumenten die eindigen op een backslash (bijvoorbeeld 'test \') werden onjuist afgehandeld. In dit geval werd bij het framen van een argument met dubbele aanhalingstekens het laatste citaat geëscaped, waardoor het mogelijk werd om de vervanging van uw opties op de opdrachtregel te organiseren.
- — bij het recursief klonen van submodules (“clone —recurse-submodules”) in de Windows-omgeving onder bepaalde omstandigheden activeer het gebruik van dezelfde git-map twee keer (.git, git~1, git~2 en git~N worden herkend als één map in NTFS, maar deze situatie is alleen getest voor git~1), wat gebruikt zou kunnen worden om te organiseren schrijven naar de map ".git". Om de uitvoering van zijn code te organiseren, kan een aanvaller bijvoorbeeld zijn script vervangen door de post-checkout-handler in het .git/config-bestand.
- — de handler voor stationsnamen met letters in Windows-paden bij het vertalen van paden zoals “C:\” was alleen ontworpen om Latijnse identificaties van één letter te vervangen, maar hield geen rekening met de mogelijkheid om virtuele schijven te maken die zijn toegewezen via “subst letter:path” . Dergelijke paden werden niet als absoluut maar als relatieve paden behandeld, waardoor het bij het klonen van een kwaadaardige repository mogelijk werd een record in een willekeurige map buiten de werkmapstructuur te ordenen (bijvoorbeeld bij het gebruik van getallen of Unicode-tekens op de schijf). naam - “1:\wat\de\ hex.txt" of "ä:\tschibät.sch").
- — bij het werken op het Windows-platform, het gebruik van alternatieve datastromen in NTFS, gecreëerd door het toevoegen van het attribuut “:stream-name:stream-type” aan de bestandsnaam, bestanden in de map ".git/" overschrijven bij het klonen van een kwaadaardige repository. De naam ".git::$INDEX_ALLOCATION" in NTFS werd bijvoorbeeld behandeld als een geldige link naar de map ".git".
- — bij gebruik van Git in een WSL-omgeving (Windows Subsystem for Linux) bij toegang tot de werkmap bescherming tegen naammanipulatie in NTFS (aanvallen via FAT-naamvertaling waren mogelijk, ".git" was bijvoorbeeld toegankelijk via de directory "git~1").
- -
schrijft naar de map ".git/" op het Windows-platform bij het klonen van kwaadaardige opslagplaatsen die bestanden bevatten met een backslash in de naam (bijvoorbeeld "a\b"), wat acceptabel is op Unix/Linux, maar wordt geaccepteerd als onderdeel van het pad op Windows. - — onvoldoende controle van de namen van submodules zou kunnen worden gebruikt om gerichte aanvallen te organiseren, die, indien recursief gekloond, mogelijk zouden kunnen zijn om de code van de aanvaller uit te voeren. Git verhinderde niet het aanmaken van een submodule directory binnen de directory van een andere submodule, wat in de meeste gevallen alleen maar tot verwarring zou leiden, maar verhinderde niet potentieel dat de inhoud van een andere module werd overschreven tijdens het recursieve kloonproces (bijvoorbeeld de submodule directories "hippo" en "hippo/hooks" worden geplaatst als ".git/modules/hippo/" en ".git/modules/hippo/hooks/", en de hooks-map in hippo kan afzonderlijk worden gebruikt om getriggerde hooks te hosten.
Windows-gebruikers worden geadviseerd om hun versie van Git onmiddellijk bij te werken en tot de update geen niet-geverifieerde repository's te klonen. Als het nog niet mogelijk is om de Git-versie dringend bij te werken, dan is het, om het risico op een aanval te verminderen, aanbevolen om “git clone —recurse-submodules” en “git submodule update” niet uit te voeren met ongecontroleerde repositories, en niet om “git te gebruiken fast-import” met ongecontroleerde invoerstromen, en niet om opslagplaatsen naar NTFS-gebaseerde partities te klonen.
Voor extra veiligheid verbieden nieuwe releases ook het gebruik van constructies in de vorm "submodule.{name}.update=!command" in .gitmodules. Voor distributies kunt u de release van pakketupdates op de pagina's volgen ,, , , , , , .
Bron: opennet.ru