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.
Komentarze
Czyli hostingi współdzielone mogą mieć spore kłopoty
Właśnie… Jak to wygląda w przypadku parawirtualizacji?
Wydaje się nie działać na kernelu z grsec. Ciekawe czy grsec blokuje sam atak czy tylko ten konkretny exploit?
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
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.
U mnie na jednym serwerze, na którym mam grsecurity nie udało mi się odpalając ten exploit podmienić zawartości pliku.
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.
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…
w sumie update :) juz działa.
Dziala na Slackware 14.2 z kernelem 4.4.19.
Slackware 14.2 kernel 4.4.5
Grsec robi dobra robote, żaden z 8 zero day-ów nie działa.
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.
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.
45sek? łał :) nowszym HP gen8-9 to na sam POST schodzi 10 minut ;)
Kolega to chyba na laptopie testował a nie serwerze :)
https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13
fajnie jakby po tym się te maszyny nie zawieszały ;)
:)
W openSUSE już jest poprawka.
Najlepiej zabezpieczyć separacją galwaniczną
i znowu race condition
A widzieliście ceny w sklepiku?
T-shirt za ponad 2tys euro?
Czy tylko ja źle widzę.
@bronislaw: Źle widzisz. Nie 2000 Euro a 2788 Euro. :)
A Centos z jąderem 2.6.32 jest najwyraźniej odporny.