15-letnia luka 0day w Makach: root dla każdego szkodnika, a łatki wciąż brak

Strona główna Aktualności
image

O autorze

Nowy rok zaczyna się dla Apple bardzo starym bugiem. Podatność występująca w systemie macOS (który nazywał się wtedy jeszcze Mac OS X) od przynajmniej 15 lat, została wykorzystana przez hakera o pseudonimie s1guza do zbudowania exploitu, pozwalającego na zdobycie uprawnień administratora przez dowolny nieuprzywilejowany proces. Twórcy złośliwego oprogramowania na Maka mogą być zadowoleni – w Sieci pojawił się nie tylko gotowy exploit, ale też i kompletna dokumentacja luki. Apple jak to Apple milczy, póki co łatki brak.

Jeden mały, brzydki błąd, popełniony w czasie, gdy Maki korzystały jeszcze z architektury PowerPC. Zapewne tygodnie męczącej pracy i niezwykła chęć jej udokumentowania – rzadko się zdarza atak tak dokładnie udokumentowany, jak zrobił to Siguza. IOHIDFamily to rozszerzenie kernela, które dostarcza abstrakcyjny interfejs dla urządzeń interfejsu użytkownika (HID). Rozszerzenie to występuje zarówno w macOS-ie jak i iOS-ie, jednak na Maku jest obszerniejsze. Zawiera klasę o nazwie IOHIDSystem, w którym właśnie znalazła się podatność.

W ogromnym uproszczeniu można powiedzieć, że wspomniana klasa zawiera trzy klienty użytkownika, z których jeden, IOHIDUserClient, ma ogromne uprawnienia w systemie, a podczas normalnej pracy może występować tylko jedna jego instancja, sterowana przez WindowServer, czyli systemowy komponent rysujący wszystko co widzimy na ekranie. Cały ten system oferuje pewną ilość pamięci na kolejkę wydarzeń i dane związane z kursorem, które może przekazać do przestrzeni adresowej WindowServera. Mamy oczywiście funkcje do zarządzania tą pamięcią, a jedna z nich, IOHIDSystem::initShmem służy do czyszczenia i inicjalizacji struktur danych. I to ona jest szczególnie interesująca, można bowiem zmieniać w niej wartość globalnego offsetu i zmusić wskaźnik by wskazywał gdzie indziej, niż zamierzano.

Zbudowanie exploita nie było trywialne – choćby dlatego, że WindowServer trzyma sobie jedyną dostępną instancje IOHIDUserClienta i trzeba mu ją wykraść. Co więcej, trzeba było zrobić to tak, by nie potrzebować do tego roota. Haker odkrył jednak, że WindowServer na chwilę puszcza swojego klienta, w momencie wylogowania użytkownika z systemu. Można więc wymusić wylogowanie i w tym momencie mamy już naszego klienta i manipulujemy jego pamięcią. Ale wciąż przecież trzeba być użytkownikiem, by się wylogować – czy nie można zrobić tego lepiej?

Najwyraźniej można. Któryś z programistów macOS-a popadł bowiem w chwilowe szaleństwo, oprogramowując zachowanie okienka dialogowego potwierdzającego chęć wylogowania. Okienko to w ogóle nie weryfikuje skąd przyszło żądanie wylogowania, więc wylogować się może każdy proces, nawet jakieś nobody – wystarczy do tego jeden wiersz AppleScriptu.

Trzecia metoda to stworzenie programu, który działając sobie w tle, czeka na sprzyjające warunki, w końcu użytkownik swojego Maka wyłączy lub zrestartuje. W tym właśnie momencie złośliwy kod może sobie porwać potrzebnego mu IOHIDUserClienta.

Mając już dostęp, s1guza poeksperymentował z różnymi metodami uszkadzania pamięci i analizowania jej zawartości. W grę wchodzi tu spora struktura – od macOS-a 10.12.0 do 10.13.1 idzie całe dwa gigabajty RAM. Między Sierrą a High Sierrą występowały pewne różnice, ale udało się w końcu znaleźć sposób na zmaksymalizowanie szansy wylądowania tam, gdzie pamięć została zmodyfikowana za pomocą przeróżnych sztuczek ze wspomnianą funkcją IOHIDSystem::initShmem.

IOHIDeous

Udostępniony przez hakera exploit składa się z trzech elementów:

– poc (make poc): celuje we wszystkie wersje macOS-a, zawieszając kernel by wykazać istnienie uszkodzenia pamięci,
– leak (make leak): celuje w macOS-a High Sierra, by udowodnić że nie potrzeba tu specjalnego obejścia KASLR,
– hid (make hid): celuje w macOS-a Sierra i High Sierra, zapewniając pełen dostęp do systemu i wyłączając System Integrity Protection, by pokazać, że nieuprzywilejowany użytkownik może zrobić to wszystko.

Pozostaje jeszcze poradzić sobie z zabezpieczeniami samego kernela (KASLR) – co już samo w sobie było niezłym wyczynem. Proces ten zajmuje 12 kroków, prowadzących do zbudowania fałszywego zadania pod określonym adresem i zmuszenia portu zadań kernela do jego odczytania. Kolejną częścią układanki jest atak ROP (Return-oriented programming), który prowadzi do uzyskania roota, a następnie podłączenie portu zadań kernela do przestrzeni użytkownika, zainstalowanie powłoki z uprawnieniami roota i wyłączenie obsługi podpisów plików wykonywalnych oraz blokady modyfikacji plików systemowych. Efekt? macOS przechodzi pod pełną kontrolę napastnika. Jedyną pociechą jest to, że nie jest to atak zdalny, exploit musi znaleźć się na maszynie ofiary.

Wraz z rosnącą popularnością Maków takich starych luk w systemie znajdzie się pewnie jeszcze więcej. System Apple’a wydaje się ogromnie skomplikowany, jest w nim pełno „ruchomych” części… a to oznacza, że wiele można w tym wszystkim popsuć. Użytkownikom można jedynie poradzić, by korzystali z antywirusów i nie uruchamiali oprogramowania z podejrzanych źródeł. Jak widać po tym ataku 0day, jedno kliknięcie w może doprowadzić to tego, że wasz komputer przestanie należeć do was.

© dobreprogramy