wydania korygujące rozproszonego systemu kontroli źródła 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 i 2.14.62.24.1 XNUMX, który naprawił luki umożliwiające atakującemu przepisanie dowolnych ścieżek w systemie plików, zorganizowanie zdalnego wykonania kodu lub nadpisanie plików w katalogu „.git/”. Większość problemów zidentyfikowanych przez pracowników
Microsoft Security Response Center, pięć z ośmiu luk jest specyficznych dla platformy Windows.
- — polecenie przesyłania strumieniowego „feature eksport-marks=path” zapisuj etykiety do dowolnych katalogów, których można użyć do nadpisania dowolnych ścieżek w systemie plików podczas wykonywania operacji „git fast-import” z niesprawdzonymi danymi wejściowymi.
- - niepoprawna ucieczka argumentów linii poleceń do zdalnego wykonania kodu atakującego podczas klonowania rekurencyjnego przy użyciu adresu URL ssh://. W szczególności nieprawidłowo obsłużono argumenty ucieczki zakończone ukośnikiem odwrotnym (na przykład „test \”). W tym przypadku, umieszczając argument w cudzysłowie, ostatni cudzysłów został usunięty, co umożliwiło zorganizowanie podstawienia opcji w wierszu poleceń.
- — przy rekurencyjnym klonowaniu submodułów („clone —recurse-submodules”) w środowisku Windows pod pewnymi warunkami wywołać dwukrotne użycie tego samego katalogu git (.git, git~1, git~2 i git~N są rozpoznawane w systemie plików NTFS jako jeden katalog, ale sytuacja ta została przetestowana tylko dla git~1), który mógłby zostać wykorzystany do organizowania zapis do katalogu „.git”. Aby zorganizować wykonanie swojego kodu, osoba atakująca może na przykład zastąpić swój skrypt za pomocą modułu obsługi po zakupie w pliku .git/config.
- — procedura obsługi literowych nazw dysków w ścieżkach Windows podczas tłumaczenia ścieżek typu „C:\” została zaprojektowana wyłącznie w celu zastąpienia jednoliterowych identyfikatorów łacińskich, ale nie uwzględniała możliwości tworzenia dysków wirtualnych przypisanych poprzez „podrzędną literę:ścieżka” . Ścieżki takie traktowano nie jako ścieżki bezwzględne, lecz względne, co umożliwiało podczas klonowania szkodliwego repozytorium zorganizowanie rekordu w dowolnym katalogu poza drzewem katalogów roboczych (np. przy użyciu liczb lub znaków Unicode na dysku nazwa - „1:\what\the\hex.txt” lub „ä:\tschibät.sch”).
- — w przypadku pracy na platformie Windows wykorzystanie alternatywnych strumieni danych w systemie NTFS, utworzonych poprzez dodanie do nazwy pliku atrybutu „:stream-name:stream-type”, nadpisz pliki w katalogu „.git/” podczas klonowania złośliwego repozytorium. Na przykład nazwa „.git::$INDEX_ALLOCATION” w systemie NTFS była traktowana jako prawidłowe łącze do katalogu „.git”.
- — podczas korzystania z Git w środowisku WSL (podsystem Windows dla systemu Linux) podczas uzyskiwania dostępu do katalogu roboczego ochrona przed manipulacją nazwami w systemie NTFS (możliwe były ataki poprzez translację nazw FAT, np. dostęp do pliku „.git” można było uzyskać poprzez katalog „git~1”).
- -
zapisuje do katalogu „.git/” na platformie Windows podczas klonowania złośliwych repozytoriów zawierających pliki z ukośnikiem odwrotnym w nazwie (na przykład „a\b”), co jest dopuszczalne w systemie Unix/Linux, ale jest akceptowane jako część ścieżkę w systemie Windows. - — niedostateczne sprawdzanie nazw podmodułów mogłoby zostać wykorzystane do zorganizowania ataków ukierunkowanych, które w przypadku rekurencyjnego sklonowania mogłyby potencjalnie do wykonania kodu atakującego. Git nie zapobiegł utworzeniu katalogu podmodułu w katalogu innego podmodułu, co w większości przypadków prowadziłoby jedynie do zamieszania, ale nie zapobiegł potencjalnie nadpisaniu zawartości innego modułu podczas procesu klonowania rekurencyjnego (na przykład katalogi podmodułów „hippo” i „hippo/hooks” są umieszczane jako „.git/modules/hippo/” i „.git/modules/hippo/hooks/”, a katalog hooks w hipopotam może być oddzielnie używany do hostowania wyzwalanych hooków.
Użytkownikom systemu Windows zaleca się natychmiastową aktualizację swojej wersji Gita i powstrzymanie się od klonowania niezweryfikowanych repozytoriów do czasu aktualizacji. Jeśli nie jest jeszcze możliwa pilna aktualizacja wersji Git, to aby zmniejszyć ryzyko ataku, zaleca się nie uruchamiać „git clone —recurse-submodules” i „git submodule update” z niesprawdzonymi repozytoriami, nie używać „git fast-import” z niesprawdzonymi strumieniami wejściowymi, a nie klonowanie repozytoriów na partycje oparte na systemie plików NTFS.
Aby zwiększyć bezpieczeństwo, nowe wersje zabraniają również używania konstrukcji w postaci „submodule.{name}.update=!command” w .gitmodules. W przypadku dystrybucji możesz śledzić wydawanie aktualizacji pakietów na stronach ,, , , , , , .
Źródło: opennet.ru