Poprawki w zdalnym systemie zarządzania kodem źródłowym 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 oraz 2.14.6, które eliminują luki umożliwiające atakującemu zapisanie dowolnych ścieżek w systemie plików, zdalne uruchomienie kodu lub nadpisanie plików w katalogu '.git/'. Większość problemów została wykryta przez pracowników
Microsoft Security Response Center, pięć z ośmiu luk jest specyficznych dla platformy Windows.
- — polecenie strumieniowe 'feature export-marks=path' zapisuje markery do dowolnych katalogów, co może prowadzić do nadpisania dowolnych ścieżek w systemie plików podczas wykonywania operacji 'git fast-import' z niezweryfikowanymi danymi wejściowymi.
- — błędne kodowanie argumentów w wierszu poleceń do zdalnego wykonania kodu przez atakującego przy rekurencyjnym klonowaniu za pomocą adresu URL ssh://. W szczególności błędnie obsługiwano kodowanie argumentów kończących się na odwrotnym ukośniku (np. 'test \'). W tym przypadku przy otoczeniu argumentu podwójnymi cudzysłowami, ostatni cudzysłów był kodowany, co pozwalało na wprowadzenie własnych opcji w wierszu poleceń.
- — podczas rekurencyjnego klonowania submodułów ('clone —recurse-submodules') w środowisku Windows w określonych warunkach inicjować użycie jednego katalogu git dwukrotnie (.git, git~1, git~2 i git~N w NTFS są rozpoznawane jako jeden katalog, ale ta sytuacja była weryfikowana tylko dla git~1), co mogło prowadzić do zapisu w katalogu '.git'. Aby zrealizować wykonanie własnego kodu, atakujący mógł na przykład wprowadzić swój skrypt przez handler post-checkout w pliku .git/config.
- — handler literowych nazw dysków w ścieżkach Windows podczas translacji ścieżek typu 'C:\' był zaprojektowany tylko do zamiany jednowyrazowych, łacińskich identyfikatorów, ale nie uwzględniał możliwości tworzenia wirtualnych dysków przypisywanych przez 'subst litera:ścieżka'. Takie ścieżki były traktowane jako względne, a nie absolutne, co pozwalało podczas klonowania złośliwego repozytorium na zapis do dowolnego katalogu poza drzewem roboczym katalogów (np. przy użyciu cyfr lub znaków unicode w nazwie dysku — '1:\what\the\hex.txt' lub 'ä:\tschibät.sch').
- — podczas pracy na platformie Windows zastosowanie alternatywnych strumieni danych w NTFS, tworzonych przez dodanie znacznika „:stream-name:stream-type” do nazwy pliku, może umożliwić nadpisanie plików w katalogu „.git/” podczas klonowania złośliwego repozytorium. Na przykład, nazwa „.git::$INDEX_ALLOCATION” w NTFS była traktowana jako poprawne odniesienie do katalogu „.git”.
- — podczas używania Gita w środowisku WSL (Windows Subsystem for Linux) przy dostępie do katalogu roboczego ochrona przed manipulacją nazwami w NTFS (możliwe były ataki za pomocą translacji nazw FAT, na przykład, do „.git” można było podejść poprzez katalog „git~1”).
- —
zapisy do katalogu „.git/” na platformie Windows podczas klonowania złośliwych repozytoriów, zawierających pliki z odwrotnym ukośnikiem w nazwie (na przykład „a\b”), który jest dozwolony w Unix/Linux, ale traktowany jako część ścieżki w Windows. - — niedostateczna weryfikacja nazw submodułów mogła zostać wykorzystana do przeprowadzenia ataków ukierunkowanych, które podczas rekurencyjnego klonowania potencjalnie do wykonania kodu atakującego. Git nie zabraniał tworzenia katalogu submodułu w katalogu innego submodułu, co w większości przypadków jedynie może prowadzić do zamieszania, ale potencjalnie nie wyklucza nadpisania zawartości innego modułu w trakcie rekurencyjnego klonowania (na przykład, katalogi submodułów „hippo” i „hippo/hooks” są umieszczane jako „.git/modules/hippo/” i „.git/modules/hippo/hooks/”, a katalog hooks w hippo może być osobno używany do umieszczania wywoływanych obsługujących).
Użytkownikom Windows zaleca się pilne zaktualizowanie wersji Gita, a do czasu aktualizacji wstrzymanie klonowania niezweryfikowanych repozytoriów. Jeśli nie ma możliwości pilnej aktualizacji wersji Gita, to w celu ograniczenia ryzyka ataku zaleca się nie uruchamianie „git clone —recurse-submodules” i „git submodule update” z niezweryfikowanymi repozytoriami, nie używanie „git fast-import” z niezweryfikowanymi strumieniami danych i nie klonowanie repozytoriów do partycji na bazie NTFS.
Dla dodatkowej ochrony w nowych wydaniach także zabroniono stosowania w .gitmodules konstrukcji w formie „submodule.{name}.update=!command”. W dystrybucjach można śledzić wydanie aktualizacji pakietów na stronach ,, , , , , , .
Źródło: opennet.ru
