16.03.2016 | 09:54

Adam Haertle

[AKTUALIZACJA] Poważny błąd we wszystkich wersjach Gita do 2.7.3 włącznie!

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

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 ;)

Powrót

Komentarze

  • 2016.03.16 10:04 wojtek

    najciemniej pod latarnia :)

    Odpowiedz
  • 2016.03.16 10:19 Koziołek

    No to się zaktualizuje… w czym problem. Win10 mi to nie zainstaluje :D

    Odpowiedz
  • 2016.03.16 19:32 grsec

    i tam lubię kompilować ;)

    Odpowiedz
  • 2016.03.16 20:10 Rafał

    aktualnie mam 2.7.3 na win 10 ale chyba czas kompilować z ręki :)

    Odpowiedz
  • 2016.03.17 02:38 Kawlakada

    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ę.

    Odpowiedz
  • 2016.03.17 13:09 ruby hacker

    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.

    Odpowiedz
    • 2016.03.18 00:03 MatM

      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.

      Odpowiedz
  • 2016.03.17 18:22 jangorecki

    a na niebezpie3niq w komentarzach przekonuja ze windows bezpieczniejszy :D

    Odpowiedz
  • 2016.03.18 13:59 Norbitor

    Z tego, co widzę. To wydali już wersję 2.7.4 Gita, która ma już odpowiedniego fiksa.

    Odpowiedz
  • 2016.03.18 18:50 Majaki

    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.

    Odpowiedz
    • 2016.03.18 20:41 Adam

      Może ten fragment artykułu coś wyjaśni „Po stronie klienta błąd wywołuje próba sklonowania spreparowanego repozytorium”

      Odpowiedz
      • 2016.03.19 13:02 MatM

        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.

        Odpowiedz

Zostaw odpowiedź do MatM

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

[AKTUALIZACJA] Poważny błąd we wszystkich wersjach Gita do 2.7.3 włącznie!

Komentarze