21.10.2016 | 10:49

Adam Haertle

Masz serwer z jądrem Linux? To lepiej go załataj póki czas

Jeśli nie chcesz, by Twój serwer padł ofiarą trywialnego ataku, lepiej zainstaluj najnowsze aktualizacje. Błąd co prawda umożliwia „tylko” podniesienie uprawnień, ale jest bardzo łatwy do wykorzystania i dotyka chyba każdej dystrybucji.

Błędy podniesienia uprawnień z reguły przyciągają mniejszą uwagę mediów, ponieważ scenariusze ich wykorzystania stają się automatycznie bardziej skomplikowane – najpierw trzeba mieć dostęp do serwera. W tym wypadku nie jest inaczej, jednak uniwersalność tego błędu powoduje, że zapewne będzie on często wykorzystywany w atakach (znaleziony został na zhakowanym serwerze), zatem warto napisać kilka słów by ostrzec administratorów.

Kto, co, gdzie, jak

Błąd o numerze CVE 2016-5195 otrzymał nazwę marketingową Dirty COW. Ma oczywiście swoją stronę internetową, logo a nawet sklepik z gadżetami, lecz niech te fakty nie przyćmią prawdziwej wagi problemu. Błąd ten ma kilka cech, które czynią go prawdopodobnie ulubionym narzędziem włamywaczy i pentesterów w najbliższych miesiącach, jeśli nie latach:

  • jest bardzo prosty w wykorzystaniu, działa zawsze,
  • jest uniwersalny, działa na wielu dystrybucjach,
  • nie zostawia śladów.

Choć daleko nam do technicznych ekspertów, to spróbujemy opisać jego działanie (tu znajdziecie profesjonalnie opisane szczegóły podatności). Problem znajduje się w sposobie, w jaki Linux obsługuje technikę kopiowania pamięci zwaną kopiowanie przy zapisie (copy on write, stąd skrót COW w nazwie błędu). Technika polega na wstrzymaniu się z kopiowaniem danych, dopóki nie zostaną one zmodyfikowane – wcześniej wykorzystywany jest wskaźnik do lokalizacji tych danych, by nie kopiować ich niepotrzebnie. Niestety błąd w kodzie jądra powoduje, że możliwa staje się tzw. sytuacja wyścigu, gdzie inny proces dokonuje zmian w obszarze pamięci zanim zostanie on skopiowany. Dzięki temu zwykły użytkownik, który teoretycznie nie ma uprawnień zapisu do chronionego obszaru pamięci, może taki dostęp uzyskać i zmodyfikować kluczowe dane, w szczególności nadając sobie uprawnienia administratora.

Prześledzenie historii kodu jądra Linux wskazuje, że błąd istniał już w roku 2007. Nie wiadomo, czy był wykorzystywany we wcześniejszych atakach. Na jego ślad trafił dopiero Phil Oester, który kilka lat temu wpadł na ciekawy pomysł i zaczął na swoich serwerach zapisywać do pliku pełną treść przychodzących pakietów w ramach protokołu HTTP. Gdy jeden z jego serwerów został zhakowany, Phil prześledził działania włamywacza, odzyskał z kopii ruchu treść exploita użytego do podniesienia uprawnień i znalazł opisywany powyżej błąd.

Warto podkreślić, że wykorzystanie błędu wymaga wcześniejszego uzyskania dostępu do atakowanego serwera. Choć zdobycie shella sprawia, że atak jest wygodniejszy do przeprowadzenia, to nie jest konieczne – wystarczy użycie dowolnego błędu np. w aplikacji WWW umożliwiającego zdalne wykonanie własnego kodu na serwerze. Ten rodzaj ataku może stać się bardzo popularny w najbliższych dniach – włamywacze, którzy wykorzystali np. błędy typu SQLi prowadzące do RCE będą mogli skorzystać ze skutecznej metody podniesienia uprawnień na zaatakowanej maszynie. Oprócz aktualizacji jądra może warto także pomyśleć o szkoleniu z bezpieczeństwa aplikacji WWW.

W sieci dostępny jest kod exploita. Możecie przetestować na swoich maszynach – podobno działa niezawodnie.

Powrót

Komentarze

  • 2016.10.21 12:12 Awganowicz

    Czyli hostingi współdzielone mogą mieć spore kłopoty

    Odpowiedz
    • 2016.10.24 12:51 BGP.pl

      Właśnie… Jak to wygląda w przypadku parawirtualizacji?

      Odpowiedz
  • 2016.10.21 12:30 Marc1n

    Wydaje się nie działać na kernelu z grsec. Ciekawe czy grsec blokuje sam atak czy tylko ten konkretny exploit?

    Odpowiedz
    • 2016.10.21 14:38 Piotr

      Brad Spengler (albo ktoś podający się za niego) napisał, że grsec nie chroni i nie może chronić przed takimi błędami.
      Źródło:
      http://lwn.net/Articles/704162/rss

      Odpowiedz
      • 2016.10.21 17:02 xxx

        Sprawdziłem u siebie na jajkach hardened (4.1.x – 4.7.x) i exploit nie działa. Więc jednak coś jest na rzeczy. Zadziałało na dwóch maszynach bez hardened.

        Odpowiedz
      • 2016.10.21 18:09 Andrzej

        U mnie na jednym serwerze, na którym mam grsecurity nie udało mi się odpalając ten exploit podmienić zawartości pliku.

        Odpowiedz
      • 2016.10.26 21:36 bratpit

        Slackware 14.2 kernel 4.4.5

        Grsec zatrzymuje atak

        po in dirtycow$ ./dirtycow-mem
        [*] range: 3a6aa239000-3a6aa3f9000]
        [*] getuid = 3a6aa305b30
        [*] mmap 0x3a6aa03d000
        [*] exploiting (patch)
        dirtycow-mem: open(„/proc/self/mem”: Permission denied

        Inny exploit z wykorzystaniem PTRACE też zatrzymany .

        Wszystkie PoC-e z githab zatrzymane dzieki Grsec.

        Odpowiedz
  • 2016.10.21 12:35 Karol

    Skompilowałem i przyznam, że nie działa … [4.4.21-gentoo]. Albo jeszcze jeden myk do tego shella, tak jak konieczna modyfikacja w C by przekompilowac…

    Odpowiedz
    • 2016.10.21 12:39 Karol

      w sumie update :) juz działa.

      Odpowiedz
  • 2016.10.21 14:51 Trolecki Jan

    Dziala na Slackware 14.2 z kernelem 4.4.19.

    Odpowiedz
    • 2016.10.26 20:36 bratpit

      Slackware 14.2 kernel 4.4.5
      Grsec robi dobra robote, żaden z 8 zero day-ów nie działa.

      Odpowiedz
  • 2016.10.21 15:11 zatroskany

    Działa działa… to będzie pracowity weekend dla itsec, spodziewajcie się wielu komunikatów:

    „W związku z potrzebą uaktualnienia oprogramowania serwis/usługa xyz nie będzie dostępny od .. do.. Przepraszamy blabla”

    Swoją drogą komuś zepsuła się niezła zabawka. Pewnie teraz się zastanawia czy było warto łamać ten serwer, na którym się zapisywało całość ruchu HTTP.

    Odpowiedz
    • 2016.10.21 20:40 Trolecki Jan

      Co ty bredzisz. Instalujesz nowego kernela, robisz reboot i dziala. Testowalem dzis i cala przerwa trwala jakies 45sekund. Byl to co prawda Xeon z SSD, ale przy slabszej konfiguracji nie powinno to zajac wiecej niz dwie minuty na serwer. A jak masz to jeszcze w balancingu/ failoverze to w ogole nie bedzie widac.

      Odpowiedz
      • 2016.10.24 13:55 a.nie

        45sek? łał :) nowszym HP gen8-9 to na sam POST schodzi 10 minut ;)

        Odpowiedz
      • 2016.10.25 10:16 haha

        Kolega to chyba na laptopie testował a nie serwerze :)

        Odpowiedz
  • 2016.10.21 20:56 nick

    fajnie jakby po tym się te maszyny nie zawieszały ;)

    Odpowiedz
  • 2016.10.21 22:08 Rafi X

    W openSUSE już jest poprawka.

    Odpowiedz
  • 2016.10.22 13:18 Tadzik

    Najlepiej zabezpieczyć separacją galwaniczną

    Odpowiedz
  • 2016.10.22 15:41 imje

    i znowu race condition

    Odpowiedz
  • 2016.10.23 09:08 bronislaw

    A widzieliście ceny w sklepiku?
    T-shirt za ponad 2tys euro?
    Czy tylko ja źle widzę.

    Odpowiedz
    • 2016.10.24 10:08 Mieeetek

      @bronislaw: Źle widzisz. Nie 2000 Euro a 2788 Euro. :)
      A Centos z jąderem 2.6.32 jest najwyraźniej odporny.

      Odpowiedz

Zostaw odpowiedź do bratpit

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

Masz serwer z jądrem Linux? To lepiej go załataj póki czas

Komentarze