Root dla każdego na Linuksie i Androidzie – Dirty COW głośno już ryczy w Sieci
Dirty COW (brudna krowa), czyli jedna z najciekawszych jak do tejpory luk w jądrze Linuksa, wzbudziła ogromne zainteresowaniespołeczności, otwierając drogę zarówno wyrafinowanym exploitom,jak i jailbreakom zablokowanych dotąd linuksowych urządzeń. Nicdziwnego – pozwala na niezawodne uzyskanie uprawnień roota przezpraktycznie każdą aplikację, a następnie pełen dostęp dosystemu plików. Świetna wiadomość w erze masowych ataków DDoSprzeprowadzanych przez urządzenia Internetu Rzeczy – z którychwielu 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 implementacjapojawiła się już w wydanym w 2007 roku kernelu 2.6.22 i w takiejformie pozostała do teraz. Wyjaśnijmy, co zawiodło. ZwykleCopy-on-Write wykorzystywana jest do współdzielenia dużych ilościdanych 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 jestmodyfikacja, kernel kopiuje dane na inną stronę pamięci, tak bymógł do nich uzyskać dostęp tylko jeden proces.
Kopiuj ile wlezie
Atak polega na stworzeniu warunków do zaistnienia hazardu (racecondition) w tym mechanizmie. Z przeprowadzonej przez odkrywcówDirty COW analizy wynika, że wystarczy otworzyć należący do rootaplik wykonywalny i zarezerwować mu pamięć (można to zrobić zkaż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 zarezerwowanejpamięci.
Następnie w innym wątku tego samego procesu otwiera się plikwirtualnej pamięci procesu, do którego ma on uprawnienia odczytu izapisu (/proc/self/mem). W pliku tym poprzez normalne operacje zapisunadpisuje się obszary własnej pamięci, które zostałyzarezerwowane dla należącego do roota pliku wykonywalnego.Atakujący proces trzyma więc pamięć pliku wykonywalnego tylko doodczytu w prywatnym obszarze i w jednym wątku rozgłasza, żepamięci tej nie będzie ruszał, podczas gdy w drugim nadpisujepamięć zarezerwowaną dla tego obiektu. Próba takiego zapisupowinna uruchomić kopiowanie-przy-zapisie, tak by zmiana trafiłatylko do pamięci zarezerwowanej przez proces, nie dotykającodwzorowanego pliku.
Nie tak jednak zachowuje się linuksowy kernel. Hazardowasytuacja wywołana przez rozgłaszanie o nieużywaniu zarezerwowanejpamięci sprawia, że kernel nie przenosi w pełni wykonywalnegopliku z pamięci. Próba zapisu wywołuje oczywiście błąd, któryzostaje nawet poprawnie obsłużony – tyle że w tym wypadkumadvise() mówi, by porzucić stronę pamięci z odwzorowanym do niejobszarem. W ten sposób dane trafiają bezpośrednio do plikuwykonywalnego z uprawnieniami roota i zostają zachowane przez kernelbezpośrednio w systemie plików.
W ten sposób można więc wykorzystać dowolny należący doroota plik uruchamialny dla użytkownika, by uruchomić z niegopowłokę systemową z uprawnieniami roota – a wówczas hulajdusza, piekła nie ma, system należy do napastnika.
Co robić i jak żyć?
W sieci już znalazły się exploitywykorzystujące Brudną Krowę. Zarazem też łatka opracowana dlatego starożytnegobłędu trafiła już do linuksowych kerneli – poprawkowewersje są udostępniane m.in. w repozytoriach Debiana, Ubuntu,Fedory, OpenSUSE i Red Hata.
https://t.co/72uN9eo4VY <--Updated version of Linux COW exploit. Fully functional. Shells for days.
— daveaitel (@daveaitel) October 21, 2016Gorzej z Androidem oraz tymi wszystkimilinuksowymi urządzeniami wbudowanymi, tutaj na łatki trzeba będziejeszcze poczekać – o ile się doczekamy. Oczywiście dla wieluużytkowników telefonów nie mających roota będzie to niezłaokazja do uwolnienia swoich smartfonów. Zobaczcie zresztą sami:brudna krowa na Androidzie hasaśmiało – i to mimo tego, że Android korzysta przecież zSELinuksa, który jakoś powinien przecież blokować zapisy do/proc/self/mem.
Warto podkreślić, że sam Linus Torvalds przyznał, że ten błądpozwalający na stworzenie sytuacji hazardowej próbował naprawićjuż 11 lat temu, ale łatka okazała się wówczaswywoł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, żewyexploitowanie luki stało się bardzo łatwe – i w końcu zrobiłto badacz o imieniu Phil Oester.
