Jeśli korzystacie z narzędzia Git do kontroli wersji oprogramowania to upewnijcie się, ze zaktualizowaliście je zarówno po stronie klienta jak i serwera. Od kilku tygodni znany jest błąd umożliwiający zdalne wykonanie kodu.
Wczoraj na liście oss-sec poinformowano o istnieniu błędu typu buffer overflow we wszystkich wersjach Gita starszych niż 2.7.1 (czyli istniał od wielu lat) zarówno po stronie serwera jak i klienta (CVE-2016-2324 i CVE-2016-2315). Błąd związany jest z nieprawidłowym przetwarzaniem zbyt długich nazw plików lub struktur katalogów. Informacja o błędzie pojawiła się na początku lutego na liście mailingowej poświęconej bezpieczeństwu projektu Git, lecz mimo szybkiej aktualizacji kodu niewiele osób zwróciło na nią uwagę i nadal prawie wszyscy korzystali z podatnych wersji. 6 marca podatny kod został umieszczony na Pastebinie. Nie widzieliśmy kodu exploita, ale można się spodziewać że nie będzie trzeba na niego długo czekać.
Git
Błąd jest o tyle poważny, że dotyczy bardzo popularnego narzędzia, szeroko stosowanego przez programistów i obecnego w chyba wszystkich dystrybucjach linuksowych (listę podatnych wersji opublikował już Debian). Serwisy takie jak GitLab czy GitHub zaktualizowały swój kod, jednak dystrybucje Linuksa do tej pory nie spieszyły się z aktualizacjami.
Aby błąd wywołać po stronie serwera trzeba wysłać do niego odpowiednio spreparowane repozytorium, co nieco ogranicza powierzchnię ataku ponieważ w wielu przypadkach wymaga wcześniejszego uwierzytelnienia. Po stronie klienta błąd wywołuje próba sklonowania spreparowanego repozytorium.
Więcej o samym błędzie możecie poczytać w tym artykule, ale najpierw zalecamy aktualizację Gita do wersji 2.7.3.
Aktualizacja: Niestety okazuje się, że aktualna wersja Gita, 2.7.3 również jest podatna na ten sam błąd. Odkrywca błędów, który dzisiaj powiadomił o nich świat, myślał, że skoro jest opracowana łata, to została ona już dołączona do projektu. Niestety był w błędzie i wersja 2.7.3 jest również podatna – łata nie została do tej pory uwzględniona w wydanych wersjach, znajduje się jednak w najnowszej wersji kodu źródłowego. Pozostaje zatem kompilować ze źródeł, jak zwierzęta ;)
Komentarze
najciemniej pod latarnia :)
No to się zaktualizuje… w czym problem. Win10 mi to nie zainstaluje :D
i tam lubię kompilować ;)
aktualnie mam 2.7.3 na win 10 ale chyba czas kompilować z ręki :)
Stara prawda, znana od zarania dziejów elektronicznego świata:
„Kto Sam Nie Kompiluje, Ten Głupi i Dużo Ryzykuje” :)
– Pozdrawiam i dziękuję za uwagę.
Tak się kończy pisanie dużego oprogramowania w prymitywnym C. Jest tyle lepszych, bezpieczniejszych języków, na przykład LISP, Python, Ruby. Ale nie, kuce uparły się na pisanie rozbudowanego softu w języku, który stoi tylko krok wyżej od asemblera.
Twórcy GIT-a mieli (i mają) powody aby go tworzyć właśnie w C. Najpopularniejsza alternatywa (Mercurial) napisany w Pythonie nie zdobył szerszego uznania i nawet twórcy Pythona migrowali do Git-a z hg. Oczywiście powody były dużo bardziej merytorycznie niż język w jakim został zakodowany sam SCM.
,
Co do samych języków to tak się składa, że każdy ma swoje wady i zalety oraz każdy umożliwia lub uniemożliwia popełnienie pewnego typu błędów w kodzie źródłowym. To, że w Pythonie czy Ruby ograniczono możliwości popełnienia błędów w zarządzaniu pamięcią nie oznacza, że je całkowicie wyeliminowano oraz że nie ma innych niebezpieczeństw nieobecnych w C.
a na niebezpie3niq w komentarzach przekonuja ze windows bezpieczniejszy :D
Z tego, co widzę. To wydali już wersję 2.7.4 Gita, która ma już odpowiedniego fiksa.
niby jak ten błąd ma wpłynąć na bezpieczeństwo klienta? Rozumiem że błąd może dotyczyć serwera a klienta? Przecież to nie usługa która działa w tle.
Może ten fragment artykułu coś wyjaśni „Po stronie klienta błąd wywołuje próba sklonowania spreparowanego repozytorium”
Autorowi zapewne chodziło o to, że do położenia klienta potrzeba znaczącej współpracy ze strony użytkownika – musi świadomie sklonować „zarażone” repo. Zdalne repo może być zainfekowane ale raczej jest to bardzo mało prawdopodobne w przypadku poważnych projektów. Z resztą sam GIT i zasada jego działania minimalizuje takie ryzyko. Zakładając oczywiście, że przeciętny operator gita, nie uczestniczy w osobliwych orgiach polegających na łapczywym i niekontrolowanym klonowaniu repozytoriów z sieci.
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.7.4.txt