5 maja informowaliśmy o Copy Fail, czyli podatności pozwalającej na lokalną eskalację uprawnień w systemach Linux. Nie minął tydzień i dowiadujemy się o nowej podatności Dirty Frag, która jest zbliżona do Copy Fail, natomiast skuteczna również w środowiskach „zabezpieczonych” przed ostatnią luką. Co gorsze, na ten moment nie pojawiała się stabilna aktualizacja, więc można stwierdzić, że zagrożone są wszystkie współdzielone środowiska Linux.
Osobą odpowiedzialną za znalezienie podatności Dirty Frag jest koreański badacz Hyunwoo Kim, który może pochwalić się znaczącą liczbą odkrytych błędów w kernelu Linux. Nie znalazłem informacji sugerujących, że do wykrycia błędu przyczyniła się sztuczna inteligencja, natomiast jest to oczywiście możliwe. Wyraźnie widać trend użycia AI do testów bezpieczeństwa i tworzenia exploitów – program komputerowy może wykazać się większym od człowieka „zrozumieniem” skomplikowanych aspektów działania kernela i ewentualnych błędów w napisanych lata temu instrukcjach. Użycie Dirty Frag, jak i Copy Fail, możliwe było od 2017 roku, a exploity pojawiły się po dziewięciu latach – akurat w czasach powszechnego działania sztucznej inteligencji.
Kod podatności napisany został w języku C. Do kompilacji wymagany jest wyłącznie zainstalowany kompilator gcc i nie ma potrzeby korzystania z jakichkolwiek zależności. Raz skompilowaną binarkę można uruchomić na dowolnej dystrybucji Linux z bardzo dużymi szansami na powodzenie ataku. Dodatkowo udane wykorzystanie tego konkretnego exploita umożliwi wszystkim standardowym użytkownikom dostęp do konta root wykonując polecenie su.
Po raz kolejny sprawdza się chroot – kod uruchomi się bez żadnych błędów, ale użytkownik pozostanie w „izolacji” i ostatecznie nie wyrządzi szkód wpływających na cały system operacyjny. Dla współdzielonych usług hostingowych zalecałbym korzystanie wyłącznie z chroot. Nie można uznać tego za kompleksowe zabezpieczenie, ale raczej za rozsądną praktykę minimalizowania ryzyka.
Błąd prowadzący do użycia Dirty Frag na tę chwilę nie został poprawiony. Z dużą pewnością można jednak w krótkim czasie spodziewać się aktualizacji, bo twórcy systemu AlmaLinux przygotowali własną wersję poprawki, która dostępna jest w repozytorium wydań testowych. Nie jest zalecane wdrażanie pakietów z tego repozytorium na środowiskach produkcyjnych. Zamieszczono jednak informacje o możliwości mitygacji poprzez wyłączenie „wrażliwych” modułów jądra.
Wszelkie podatności LPE cechują się tym, że ich wykonanie musi odbyć się „lokalnie”. Znacząco redukuje to wpływ takowych zagrożeń na środowiska z sensownie skonfigurowaną polityką dostępu. Prosta zasada zakłada, że publicznie powinny być osiągalne wyłącznie wymagane usługi – w ogromnej większości przypadków będzie to serwer HTTP hostujący naszą aplikację bądź też stanowiący reverse proxy. Zresztą ten serwer niekoniecznie będzie dostępny bezpośrednio, bo standardem jest już użycie Cloudflare czy własnych rozwiązań WAF/load balancer, co też ogranicza możliwość ataku na naszą aplikację. Z kolei pozostałe usługi (baza danych, storage sieciowy, systemy kolejek, ale też protokoły zdalnego dostępu, czyli SSH/RDP) powinny działać tylko w obrębie sieci wewnętrznej, a nawet dedykowanego VLAN – aby w możliwie największym stopniu filtrować dostęp. Taką konfigurację można uznać za produkcyjną, a przy tym znakomicie ograniczającą powierzchnię ataku.
W innej sytuacji są usługi hostingowe, gdzie serwer SSH jest dostępny dla „wszystkich”, a jedyne filtrowanie – w najlepszym przypadku – ogranicza się do puli adresów z danego państwa. Często zdarzają się również publiczne serwery baz danych, gdzie brak aktualizacji powiązanych z utrzymaniem przestarzałych wersji nie pomaga w zachowaniu odpowiedniego poziomu bezpieczeństwa.
Rosnąca popularność usług chmurowych, „gotowych” platform pozwalających na uruchomienie własnego serwisu WWW czy narzędzi SaaS pozwala jednak przypuszczać, że wkrótce standardowe rozwiązania hostingowe przestaną być znaczącą częścią Internetu. Już teraz podstawowe hostingi oferujące jedynie różne wersje języka PHP i bazy MySQL/PostgreSQL nie są szczególnie cenione i korzystają z nich (o ile nie ogranicza się to do odnowienia domeny czy opłacenia usługi) raczej bardzo małe przedsiębiorstwa czy osoby prywatne hostujące swoje niewielkie witryny internetowe.
Linux staje się celem ataków z uwagi na popularność jego zastosowania na ogólnie pojętych serwerach, gdzie w odróżnieniu od desktopów „rok Linuksa” trwa od dawna. Z tego powodu udany atak na dostępny publicznie serwer Linux może być bardziej opłacalny niż analogiczne działanie w kontekście Windows Server. Oferta zakupu exploitów 0-day dla systemów Windows i Linux (z wyjątkiem podatności w Windows Sandbox) jest na jednakowym poziomie i wynosi 100 tys. dolarów.
