r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościOPROGRAMOWANIE

Zainicjowany w lipcu br. przez ekspertów z Google Project Zero postawił sobie bardzo ambitny cel – wyeliminowanie luk w zabezpieczeniach wszelkiego oprogramowania, które ma coś wspólnego z Internetem. Wystarczyło kilka tygodni, by członkowie zespołu osiągnęli spektakularne rezultaty. Znany ze znęcania się nad Windows programista Tavis Ormandy znalazł tym razem mały, ale potencjalnie bolesny w skutkach błąd w linuksowej standardowej bibliotece C (glibc). Pierwszą reakcją był jednak sceptycyzm, błąd uznano za niemożliwy do wyexploitowania. Google'owi eksperci nie lubią 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 skutkach błę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 powinno zacząć 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órej przechowuje się informacje o wywołanych w programie funkcjach). Na 32-bitowej architekturze x86 pozwalało to na nadpisanie najmniej znaczącego bitu (LSB) wskaźnika do danych w segmencie stosu, w efekcie pozwalając na uruchomienie dowolnego kodu. Jak przypomina Chris Evans, członek Google Project Zero, w tamtych czasach ludzie byli zarówno zaskoczeni jak i przerażeni, że tak drobny błąd może doprowadzić do tak strasznych konsekwencji.

Tavis Ormandy to ekspert Google'a, znany m.in. z tego, że w 2010 roku, zaledwie kilka dni po odkryciu przez siebie luki w Windows XP i Windows Serverze 2003 opublikował na publicznej liście szczegóły ataku wraz z działającym exploitem, nie dając Microsoftowi żadnych szans na przygotowanie łatki. Wówczas działania Ormandy'ego bardzo spolaryzowały środowisko. Jedni jego bezwzględność pochwalili, twierdząc, że gdyby nie zrobił tego co zrobił, to Microsoft groźną lukę naprawiałby miesiącami. Inni potępiali go za wystawienie ogromnej rzeszy użytkowników na atak cyberprzestępców. Google najwyraźniej było z zachowania swojego pracownika zadowolone. Ormandy nie tylko nie otrzymał żadnej nagany, ale kilka lat później zrobił z Windows to samo, upubliczniając exploit wykorzystujący dopiero co odkrytą lukę w jądrze Windows w ciągu niespełna dnia.

r   e   k   l   a   m   a

W lipcu Ormandy zaprezentował wykorzystanie zatrutego bajtu NUL w bibliotece glibc – kluczowej w linuksowych systemach standardowej bibliotece języka C. Reakcje deweloperów glibc były bardzo wstrzemięźliwe, podkreślano że funkcje normalizacji uniemożliwią dostęp do zapisywalnego katalogu, a utwardzenie funkcji malloc (przydzielania pamięci) w glibc uniemożliwi uruchomienie exploita. Członkowie Project Zero uparli się jednak, że dadzą radę. Jak pisze Evans, wyzwanie podjął George „geohot” Hotz, znany m.in. z pokonania zabezpieczeń Playstation 3, przygotowując scenariusze ataku dla cał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 z uprawnieniami roota. Ten, kto uruchomi za pomocą takiego programu swój kod, uzyska dostęp administracyjny do maszyny. Wyexploitowanie błędu wymagało jednak pokonania randomizacji przestrzeni adresowej (ASLR) – zabezpieczenia używanego we współczesnych systemach operacyjnych. Okazuje się, że całkiem łatwo, wykorzystując polecenie ulimit, całkowicie obejść ASLR, zmuszając obraz i biblioteki pkexec do pojawienia się w określonych lokalizacjach.

W dodatku do błędu w glibc, w exploicie 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, z wykorzystaniem komunikatu o błędzie generowanym przez program, wygląda na dość uniwersalny. Zapoznać się z nim możecie na blogu Project Zero. W połączeniu z plikami setuid root, może okazać się on bardzo niebezpieczny.

Linux najwyraźniej w Google traktowany jest lepiej niż Windows, więc exploit został upubliczniony dopiero po załataniu luki w glibc, 44 dni po jej zgłoszeniu. Niezależni specjaliści zwracają uwagę na znaczenie ataku – choć działa on w obecnej formie tylko na 32-bitowych systemach, to systemów takich jest całkiem w Sieci sporo. Co prawda większość komputerów wbudowanych zamiast glibc używa biblioteki uClibc, a w Androidzie zastosowano bibliotekę Bionic libc, to jednak sporo jest dysków NAS, działających pod kontrolą rozmaitych GNU/Linuksów, jak również komputerków typu Raspberry Pi, ze specjalizowanymi dystrybucjami, wykorzystującymi glibc. Odkrycie poucza nas też, że nie ma co marnować czasu na debatowanie, czy dany błąd można wyexploitować, 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 exploit wcześniej niewyobrażalny.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.