Każdą lukę można wykorzystać: eksperci Google'a nie dali szans ważnej bibliotece Linuksa

Zainicjowany w lipcu br. przez ekspertów z Google Project Zeropostawił sobie bardzo ambitny cel – wyeliminowanie luk wzabezpieczeniach wszelkiego oprogramowania, które ma coś wspólnegoz Internetem. Wystarczyło kilka tygodni, by członkowie zespołuosiągnęli spektakularne rezultaty. Znany ze znęcania się nadWindows programista Tavis Ormandy znalazł tym razem mały, alepotencjalnie bolesny w skutkach błąd w linuksowej standardowejbibliotece C (glibc). Pierwszą reakcją był jednak sceptycyzm, błąduznano za niemożliwy do wyexploitowania. Google'owi eksperci nielubią najwyraźniej słowa niemożliwy. Udało im się stworzyćskutecznego exploita. Luka w glibc jest już załatana, ale każe sięnam zastanawiać, ile takich małych, a katastrofalnych w skutkachbłędów tkwi w używanym przez nas oprogramowaniu?

W 1998 roku badacz Olaf Kirch przedstawiłatak, który nazwał zatrutym bajtem NUL.Błąd programistyczny typu off by one (czyli pomyłka o jeden,występująca gdy np. zaczniemy pętlę od 1, podczas gdy powinnozacząć się od 0) pozwalał w nim na zapisanie bajtu NUL(oznaczającego koniec łańcucha znaków w językach C-podobnych)poza granicami aktualnej ramki stosu (czyli warstwy, w którejprzechowuje się informacje o wywołanych w programie funkcjach). Na32-bitowej architekturze x86 pozwalało to na nadpisanie najmniejznaczącego bitu (LSB) wskaźnika do danych w segmencie stosu, wefekcie pozwalając na uruchomienie dowolnego kodu. Jak przypominaChris Evans, członek Google Project Zero, w tamtych czasach ludziebyli zarówno zaskoczeni jak i przerażeni, że tak drobny błądmoże doprowadzić do tak strasznych konsekwencji.

Tavis Ormandy to ekspertGoogle'a, znany m.in. z tego, że w 2010 roku, zaledwie kilka dni poodkryciu przez siebie luki w Windows XP i Windows Serverze 2003opublikował na publicznej liście szczegóły ataku wraz zdziałającym exploitem, nie dając Microsoftowi żadnych szans naprzygotowanie łatki. Wówczas działania Ormandy'ego bardzospolaryzowały środowisko. Jedni jego bezwzględność pochwalili,twierdząc, że gdyby nie zrobił tego co zrobił, to Microsoftgroźną lukę naprawiałby miesiącami. Inni potępiali go zawystawienie ogromnej rzeszy użytkowników na atak cyberprzestępców.Google najwyraźniej było z zachowania swojego pracownikazadowolone. Ormandy nie tylko nie otrzymał żadnej nagany, ale kilkalat później zrobił z Windows to samo, upubliczniając exploitwykorzystujący dopiero co odkrytą lukę w jądrze Windows w ciąguniespełnadnia.

W lipcu Ormandy zaprezentowałwykorzystanie zatrutego bajtu NUL w bibliotece glibc – kluczowej wlinuksowych systemach standardowej bibliotece języka C. Reakcjedeweloperów glibc były bardzo wstrzemięźliwe, podkreślano żefunkcje normalizacji uniemożliwią dostęp do zapisywalnegokatalogu, a utwardzenie funkcji malloc (przydzielania pamięci) wglibc uniemożliwi uruchomienie exploita. Członkowie Project Zerouparli się jednak, że dadzą radę. Jak pisze Evans, wyzwaniepodjął George „geohot” Hotz, znany m.in. z pokonaniazabezpieczeń Playstation 3, przygotowując scenariusze ataku dlacałego zespołu. Już po kilku dniach osiagnięto sukces.

Na celownik wzięto 32-bitowąwersję Fedory i zawarte w niej polecenie pkexec,będące częścią pakietu PolicyKit. Plik ten ma ustawioną flagęsetuid root, co oznacza, że zawsze będzie uruchomiany zuprawnieniami roota. Ten, kto uruchomi za pomocą takiego programuswój kod, uzyska dostęp administracyjny do maszyny. Wyexploitowaniebłędu wymagało jednak pokonania randomizacji przestrzeni adresowej(ASLR) – zabezpieczenia używanego we współczesnych systemachoperacyjnych. Okazuje się, że całkiem łatwo, wykorzystującpolecenie ulimit,całkowicie obejść ASLR, zmuszając obraz i biblioteki pkexecdo pojawienia się w określonych lokalizacjach.

W dodatku do błędu w glibc, wexploicie wykorzystano sprytnie wyciek pamięci w pkexec,wywołując polecenie ze ścieżką składającą się z ukośnika(/), po którym następowało 469 jedynek (1). Sposób ataku, zwykorzystaniem komunikatu o błędzie generowanym przez program,wygląda na dość uniwersalny. Zapoznać się z nim możecie nabloguProject Zero. W połączeniu z plikami setuid root, może okazaćsię on bardzo niebezpieczny.

Linux najwyraźniej w Googletraktowany jest lepiej niż Windows, więc exploit zostałupubliczniony dopiero po załataniuluki w glibc, 44 dni po jej zgłoszeniu. Niezależni specjaliścizwracają uwagę na znaczenie ataku – choć działa on w obecnejformie tylko na 32-bitowych systemach, to systemów takich jestcałkiem w Sieci sporo. Co prawda większość komputerówwbudowanych zamiast glibc używa biblioteki uClibc, a w Androidziezastosowano bibliotekę Bionic libc, to jednak sporo jest dyskówNAS, działających pod kontrolą rozmaitych GNU/Linuksów, jakrównież komputerków typu Raspberry Pi, ze specjalizowanymidystrybucjami, wykorzystującymi glibc. Odkrycie poucza nas też, żenie ma co marnować czasu na debatowanie, czy dany błąd możnawyexploitować, czy też nie. Nawet jeśli deweloper przekonany jest,że „to nic groźnego”, to zawsze może znaleźć sięinteligentniejszy od niego haker, który znajdzie sposób na exploitwcześniej niewyobrażalny.