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

Root dla każdego na Linuksie i Androidzie – Dirty COW głośno już ryczy w Sieci

Strona główna AktualnościBEZPIECZEŃSTWO

Dirty COW (brudna krowa), czyli jedna z najciekawszych jak do tej pory luk w jądrze Linuksa, wzbudziła ogromne zainteresowanie społeczności, otwierając drogę zarówno wyrafinowanym exploitom, jak i jailbreakom zablokowanych dotąd linuksowych urządzeń. Nic dziwnego – pozwala na niezawodne uzyskanie uprawnień roota przez praktycznie każdą aplikację, a następnie pełen dostęp do systemu plików. Świetna wiadomość w erze masowych ataków DDoS przeprowadzanych przez urządzenia Internetu Rzeczy – z których wielu nigdy nie będzie można załatać.

Swoją nazwę ta nowa luka wzięła od mechanizmu Copy-on-Write (kopiowanie przy zapisie), którego tragicznej jakości implementacja pojawiła się już w wydanym w 2007 roku kernelu 2.6.22 i w takiej formie pozostała do teraz. Wyjaśnijmy, co zawiodło. Zwykle Copy-on-Write wykorzystywana jest do współdzielenia dużych ilości danych między procesami czy wątkami, gdy nie wiadomo, czy będą one modyfikowane. Aby uniknąć kosztownego kopiowania pamięci, zwracany jest tylko wskaźnik do danych. Tylko gdy potrzebna jest modyfikacja, kernel kopiuje dane na inną stronę pamięci, tak by mógł do nich uzyskać dostęp tylko jeden proces.

Kopiuj ile wlezie

Atak polega na stworzeniu warunków do zaistnienia hazardu (race condition) w tym mechanizmie. Z przeprowadzonej przez odkrywców Dirty COW analizy wynika, że wystarczy otworzyć należący do roota plik wykonywalny i zarezerwować mu pamięć (można to zrobić z każdym odczytywalnym dla użytkownika plikiem wykonywalnym). Jednocześnie wywołuje się funkcję kernela madvise(), przez którą mówi się, że nie będzie się wykorzystywać tej zarezerwowanej pamięci.

r   e   k   l   a   m   a

Następnie w innym wątku tego samego procesu otwiera się plik wirtualnej pamięci procesu, do którego ma on uprawnienia odczytu i zapisu (/proc/self/mem). W pliku tym poprzez normalne operacje zapisu nadpisuje się obszary własnej pamięci, które zostały zarezerwowane dla należącego do roota pliku wykonywalnego. Atakujący proces trzyma więc pamięć pliku wykonywalnego tylko do odczytu w prywatnym obszarze i w jednym wątku rozgłasza, że pamięci tej nie będzie ruszał, podczas gdy w drugim nadpisuje pamięć zarezerwowaną dla tego obiektu. Próba takiego zapisu powinna uruchomić kopiowanie-przy-zapisie, tak by zmiana trafiła tylko do pamięci zarezerwowanej przez proces, nie dotykając odwzorowanego pliku.

Nie tak jednak zachowuje się linuksowy kernel. Hazardowa sytuacja wywołana przez rozgłaszanie o nieużywaniu zarezerwowanej pamięci sprawia, że kernel nie przenosi w pełni wykonywalnego pliku z pamięci. Próba zapisu wywołuje oczywiście błąd, który zostaje nawet poprawnie obsłużony – tyle że w tym wypadku madvise() mówi, by porzucić stronę pamięci z odwzorowanym do niej obszarem. W ten sposób dane trafiają bezpośrednio do pliku wykonywalnego z uprawnieniami roota i zostają zachowane przez kernel bezpośrednio w systemie plików.

W ten sposób można więc wykorzystać dowolny należący do roota plik uruchamialny dla użytkownika, by uruchomić z niego powłokę systemową z uprawnieniami roota – a wówczas hulaj dusza, piekła nie ma, system należy do napastnika.

Co robić i jak żyć?

W sieci już znalazły się exploity wykorzystujące Brudną Krowę. Zarazem też łatka opracowana dla tego starożytnego błędu trafiła już do linuksowych kerneli – poprawkowe wersje są udostępniane m.in. w repozytoriach Debiana, Ubuntu, Fedory, OpenSUSE i Red Hata.

Gorzej z Androidem oraz tymi wszystkimi linuksowymi urządzeniami wbudowanymi, tutaj na łatki trzeba będzie jeszcze poczekać – o ile się doczekamy. Oczywiście dla wielu użytkowników telefonów nie mających roota będzie to niezła okazja do uwolnienia swoich smartfonów. Zobaczcie zresztą sami: brudna krowa na Androidzie hasa śmiało – i to mimo tego, że Android korzysta przecież z SELinuksa, który jakoś powinien przecież blokować zapisy do /proc/self/mem.

Warto podkreślić, że sam Linus Torvalds przyznał, że ten błąd pozwalający na stworzenie sytuacji hazardowej próbował naprawić już 11 lat temu, ale łatka okazała się wówczas wywoływać problemy na systemach s390. Zrezygnował z dalszych prób, ponieważ wywołanie hazardu było wówczas bardzo skomplikowane. Jednak kolejne zmiany architektury jądra sprawiły, że wyexploitowanie luki stało się bardzo łatwe – i w końcu zrobił to badacz o imieniu Phil Oester.

Wiecej informacji znajdziecie na stronie poświęconej tej luce, jak również na jej koncie na Twitterze (co za czasy, że bugi mają własne konta na Twitterze).

© 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.