Stagefright: Exploit, który zmienił Androida

Jedną z najmocniejszych stron Androida jest przede wszystkim jego charakter open source, który pozwala zainteresowanym stronom na forkowanie, modyfikowanie i redystrybucję systemu operacyjnego w sposób odpowiadający ich konkretnym potrzebom. Ale ta właśnie zaleta bycia oprogramowaniem typu open source działa jak miecz obosieczny, jeśli chodzi o kwestie złośliwego oprogramowania i bezpieczeństwa. Łatwiej jest znaleźć i naprawić błędy, jeśli masz wielu zdolnych współpracowników w projekcie, którego kod źródłowy jest dostępny bezpłatnie. Jednak rozwiązanie problemu na poziomie źródła nie często przekłada się na rozwiązanie problemu w rękach konsumenta końcowego. W związku z tym Android nie jest najlepszym wyborem, jeśli chodzi o wybór systemu operacyjnego dla potrzeb przedsiębiorstw wrażliwych na dane.

Na konferencji Google I/O 2014 firma Google po raz pierwszy podjęła działania w kierunku bezpieczniejszego i przyjaznego dla przedsiębiorstw ekosystemu, wprowadzając na rynek

Program Android For Work. W systemie Android For Work zastosowano podejście z dwoma profilami na potrzeby przedsiębiorstw, dzięki czemu administratorzy IT mogą utworzyć plik odrębne profile użytkowników dla pracowników – jeden skoncentrowany na pracy, inne pozostawiając profile osobiste pracowników używać. Dzięki zastosowaniu szyfrowania sprzętowego i zasad zarządzanych przez administratora dane służbowe i osobiste pozostają odrębne i bezpieczne. Następnie w późniejszych miesiącach więcej uwagi poświęcono Androidowi For Work, przy czym duży nacisk położono na bezpieczeństwo urządzenia przed złośliwym oprogramowaniem. Google też to planowało włącz pełne szyfrowanie urządzenia dla wszystkich urządzeń które miały zostać wydane z Androidem Lollipop od razu po wyjęciu z pudełka, ale zostało to odrzucone ze względu na problemy z wydajnością, a wdrożenie tego ruchu było opcjonalne dla producentów OEM.

Nacisk na bezpieczny system Android nie jest wyłącznie dziełem Google, ponieważ Samsung odegrał w tym dość znaczącą rolę za pośrednictwem swojego systemu Wkład KNOX na rzecz AOSP, które ostatecznie wzmocniony Android For Work. Jednak najnowsze exploity i luki w zabezpieczeniach systemu Android wskazują, że jest to trudne zadanie, jeśli chodzi o popularność w przypadku wdrożenia w przedsiębiorstwach. Przykładem jest niedawna luka w zabezpieczeniach Stagefright.

Zawartość:

• Co to jest Stagefright?
• Jak poważny jest Stagefright?
• Co odróżnia Stagefright od innych „ogromnych luk”?
• Dylemat aktualizacji
• Android, po tremie
• Uwagi końcowe

Co to jest Stagefright?

Mówiąc najprościej, Stagefright to exploit wykorzystujący bibliotekę kodów do odtwarzania multimediów w systemie Android o nazwie libstagefright. Silnik libstagefright służy do wykonywania kodu otrzymanego w postaci złośliwego wideo za pośrednictwem wiadomości MMS, w związku z czym do przeprowadzenia skutecznego ataku potrzebny jest jedynie numer telefonu komórkowego ofiary.

Skontaktowaliśmy się z naszym wewnętrznym ekspertem, starszym uznanym programistą XDA i administratorem programisty pulser_g2 aby udzielić bardziej szczegółowych wyjaśnień.

"Kiedy to piszę, exploit [Stagefright] miał zostać wyjaśniony w BlackHat [Połączyć], chociaż nie są jeszcze dostępne żadne slajdy ani szczegółowe informacje na temat białej księgi.

Dlatego podaję to wyjaśnienie bardziej jako przybliżone pojęcie o tym, co się dzieje, a nie jako bardzo szczegółowe wyjaśnienie z pełną dokładnością itp.

Na Stagefright składa się wiele różnych błędów, które mają swoje własne CVE [Typowe luki i zagrożenia] numery do śledzenia:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Niestety dostępne łatki nie są powiązane bezpośrednio z każdym CVE (tak jak powinny), więc wyjaśnienie tego będzie nieco chaotyczne.

1. [CVE-2015-1538]

W kodzie obsługi MPEG4 metadane 3GPP (elementy opisujące format i inne dodatkowe informacje, gdy wideo jest w formacie 3GPP) są błędne. Nie odrzucał metadanych, w których dane były zbyt duże, a jedynie sprawdzał, czy nie są za małe. Oznaczało to, że osoba atakująca mogła stworzyć „zmodyfikowany” lub „uszkodzony” plik, który zawierałby dłuższą część metadanych niż powinna.

Jednym z dużych wyzwań związanych z pisaniem kodu obsługującego „niezaufane” dane (tj. pochodzące od użytkownika lub z dowolnego innego miejsca znajdującego się poza kodem) jest obsługa danych o zmiennej długości. Filmy są tego doskonałym przykładem. Oprogramowanie musi dynamicznie przydzielać pamięć, w zależności od tego, co się dzieje.

W tym przypadku tworzony jest bufor jako wskaźnik do jakiejś pamięci, ale długość tablicy, na którą wskazuje, jest o jeden element za krótka. Metadane zostały następnie wczytane do tej tablicy i możliwe było, że ostatni wpis w tej tablicy nie będzie miał wartości „null” (lub zera). Ważne jest, aby ostatni element tablicy miał wartość zero, ponieważ w ten sposób oprogramowanie informuje, że tablica jest gotowa. Dzięki możliwości ustawienia ostatniej wartości na różną od zera (ponieważ tablica była potencjalnie o jeden element za mała), złośliwy kod mógłby zostać odczytany przez inną część kodu i wczytać zbyt dużo danych. Zamiast zatrzymywać się na końcu tej wartości, może w dalszym ciągu wczytywać inne dane, których nie powinien czytać.

(Zob.: OmniROM Gerrita)

2. [CVE-2015-1539]

Najkrótszy możliwy „rozmiar” metadanych powinien wynosić 6 bajtów, ponieważ jest to ciąg UTF-16. Kod przyjmuje rozmiar wartości całkowitej i odejmuje od niej 6. Jeśli ta wartość byłaby mniejsza niż 6, odejmowanie „byłoby niedostateczne” i zawijałoby się, w wyniku czego otrzymalibyśmy bardzo dużą liczbę. Wyobraź sobie, że możesz liczyć tylko od 0 do 65535. Jeśli weźmiesz liczbę 4 i odejmiesz 6, nie możesz zejść poniżej zera. Wracasz więc do 65535 i zaczynasz liczyć. To właśnie się tutaj dzieje!

Jeśli odebrano długość mniejszą niż 6, może to prowadzić do nieprawidłowego dekodowania ramek, ponieważ proces byteswap wykorzystuje zmienną len16, której wartość jest uzyskiwana z obliczeń rozpoczynających się od (rozmiar-6). Może to spowodować znacznie większą operację zamiany niż zamierzono, co spowoduje nieoczekiwaną zmianę wartości w danych ramki.

(Zob.: OmniROM Gerrita)

3. [CVE-2015-3824]

Wielka sprawa! Ten jest paskudny. Istnieje dokładne przeciwieństwo tego ostatniego problemu — przepełnienie liczby całkowitej, w przypadku którego liczba całkowita może stać się „za duża”. Jeśli dojdziesz do 65535 (na przykład) i nie możesz liczyć wyżej, przewrócisz się i przejdziesz do 0 w następnej kolejności!

Jeśli na tej podstawie przydzielasz pamięć (co właśnie robi Stagefright!), w tablicy zostanie przydzielona o wiele za mało pamięci. Umieszczenie w tym miejscu danych mogłoby potencjalnie spowodować nadpisanie niepowiązanych danych danymi kontrolowanymi przez twórcę złośliwego pliku.

(Zob.: OmniROM Gerrita)

4. [CVE-2015-3826]

Kolejny paskudny! Bardzo podobny do poprzedniego - kolejne przepełnienie liczby całkowitej, w którym tablica (używana jako bufor) byłaby zbyt mała. Umożliwiłoby to nadpisanie niepowiązanej pamięci, co znowu jest złe. Ktoś, kto może zapisywać dane w pamięci, może uszkodzić inne, niepowiązane dane i potencjalnie wykorzystać to do uruchomienia kontrolowanego przez siebie kodu na Twoim telefonie.

(Zob.: OmniROM Gerrita)

5. [CVE-2015-3827]

Całkiem podobne do tych ostatnich. Zmienna jest używana podczas pomijania części pamięci, a podczas odejmowania można uzyskać wartość ujemną (jak powyżej). Spowodowałoby to bardzo dużą długość „pominięcia”, przepełnienie bufora i umożliwienie dostępu do pamięci, do której nie należy uzyskać dostępu.

(Zob.: OmniROM Gerrita)

Istnieje również kilka (potencjalnie) powiązanych poprawek, które prawdopodobnie trafiły również do [Androida] 5.1.

(Zob.: OmniROM Gerrita)

Dodaje to kontrole, aby zatrzymać problemy z wcześniejszą poprawką bezpieczeństwa, aby dodać kontrole granic, które same w sobie mogą zostać przepełnione. W C liczby, które można przedstawić jako int ze znakiem, są przechowywane jako int ze znakiem. W przeciwnym razie pozostają niezmienione podczas operacji. Podczas tych kontroli niektóre liczby całkowite mogły zostać zapisane ze znakiem (a nie bez znaku), co później obniżyłoby ich maksymalną wartość i umożliwiłoby wystąpienie przepełnienia.

(Zob.: OmniROM Gerrita)

Więcej niedomiarów w liczbach całkowitych (gdzie liczby są zbyt małe, a następnie na tych liczbach przeprowadza się odejmowanie, co pozwala uzyskać wartość ujemną). To znowu prowadzi do dużej liczby, a nie małej, i powoduje te same problemy, co powyżej.

(Zob.: OmniROM Gerrita)

I na koniec kolejne przepełnienie liczby całkowitej. Tak jak poprzednio, wkrótce będzie używany gdzie indziej i może się przepełnić.

(Zob.: OmniROM Gerrita)"

Jak poważny jest Stagefright?

Zgodnie z post na blogu opublikowany przez macierzystą firmę badawczą, Zimperium Research Labs, exploit Stagefright potencjalnie ujawnia 95% urządzeń z Androidem – około 950 milionów – jest narażonych na tę lukę, ponieważ dotyczy ona urządzeń z systemem Android 2.2 i w górę. Co gorsza, urządzenia starsze niż Jelly Bean 4.3 są narażone na „najgorsze ryzyko”, ponieważ nie zawierają odpowiednich zabezpieczeń przeciwko temu exploitowi.

Jeśli chodzi o obrażenia, jakie może zadać Stagefright, pulser_g2 zauważył:

[blockquoteauthor="pulser_g2"]"Sam w sobie Stagefright dawałby dostęp użytkownikowi systemu przez telefon. Aby jednak nadużyć, musiałbyś ominąć ASLR (randomizację układu przestrzeni adresowej). Na razie nie wiadomo, czy udało się to osiągnąć. Ten exploit umożliwia uruchomienie „dowolnego kodu” na Twoim urządzeniu jako użytkownik systemu lub nośnika. Mają one dostęp do dźwięku i kamery na urządzeniu, a użytkownik systemu jest doskonałym miejscem do uruchomienia exploita roota. Pamiętasz wszystkie niesamowite exploity rootowania, których użyłeś do zrootowania telefonu?

Można je potencjalnie po cichu wykorzystać do uzyskania roota na swoim urządzeniu! Ten, kto ma root, jest właścicielem telefonu. Musieliby ominąć SELinux, ale TowelRoot sobie z tym poradził i PingPong też sobie poradził. Gdy już zrootują, wszystko w Twoim telefonie będzie dla nich otwarte. Wiadomości, klucze itp.”[/blockquote]Mówiąc o najgorszych scenariuszach, do dostarczenia kodu i uruchomienia tego exploita potrzebna jest tylko wiadomość MMS. Użytkownik nie musi nawet otwierać wiadomości ponieważ wiele aplikacji do przesyłania wiadomości wstępnie przetwarza MMS-y, zanim użytkownik z nimi wejdzie w interakcję. Różni się to od ataków typu spear-phishing, ponieważ użytkownik może być całkowicie nieświadomy udanego ataku, naruszającego wszystkie obecne i przyszłe dane w telefonie.

Co odróżnia Stagefright od innych „ogromnych luk”?

„Wszystkie luki w zabezpieczeniach stwarzają pewne ryzyko dla użytkowników. Ten jest szczególnie ryzykowny, ponieważ jeśli ktoś znajdzie sposób na zdalny atak (tzn możliwe, jeśli znaleziono sposób na obejście ASLR), może zostać uruchomiony, zanim w ogóle zorientujesz się, że jesteś poniżej atak"

Starsze exploity, takie jak przejęcie instalatora Androida, FakeID, a także exploity root, takie jak TowelRoot i PingPong, wymagają w pewnym momencie interakcji użytkownika, aby mogły zostać wykonane. Chociaż są one nadal „wykorzystywane” w tym sensie, że złośliwie użyte mogą spowodować wiele szkód, faktem pozostaje, że Stagefright teoretycznie potrzebuje jedynie numeru telefonu ofiary, aby zamienić telefon w trojana i dlatego ostatnio poświęca się mu tak wiele uwagi dni.

Android nie jest jednak całkowicie zdany na łaskę tego exploita. Główny inżynier ds. bezpieczeństwa Androida, Adrian Ludwig, rozwiał pewne wątpliwości w artykule: Wpis w Google+:

[blockquoteauthor="Adrian Ludwig"]"Panuje powszechne, błędne założenie, że każdy błąd oprogramowania można przekształcić w exploit bezpieczeństwa. W rzeczywistości większości błędów nie można wykorzystać, a Android zrobił wiele rzeczy, aby zwiększyć te szanse…

Lista niektórych technologii, które zostały wprowadzone od czasu Ice Cream Sandwich (Android 4.0) znajduje się na liście Tutaj. Najbardziej znana z nich to randomizacja układu przestrzeni adresowej (ASLR), która została w pełni ukończona w systemie Android 4.1 z obsługą PIE (pliki wykonywalne niezależne od pozycji) i jest obecnie dostępny w ponad 85% Androida urządzenia. Technologia ta utrudnia atakującemu odgadnięcie lokalizacji kodu, co jest wymagane do zbudowania udanego exploita...

Nie poprzestaliśmy na ASLR, dodaliśmy także NX, FortifySource, Relokacje tylko do odczytu, Stack Canaries i wiele więcej.”[/blockquote]

Jednak nadal nie można zaprzeczyć, że Stagefright to poważna sprawa dla przyszłości Androida i jako taka jest traktowana poważnie przez zainteresowane strony. Stagefright zwrócił także uwagę na białe słonie w pomieszczeniu – problem fragmentacji i aktualizacji, które w końcu docierają do konsumenta.

Dylemat aktualizacji

A skoro mowa o aktualizacjach, dobrze jest widzieć, że producenci OEM biorą odpowiedzialność za bezpieczeństwo użytkowników, tak jak obiecało wielu ulepszyć proces aktualizacji, szczególnie w celu dodania poprawek bezpieczeństwa i łat dla exploitów takich jak Stagefright.

Google obiecał, że będzie jednym z pierwszych, którzy opublikują oficjalne oświadczenie comiesięczne aktualizacje zabezpieczeń (oprócz planowanych aktualizacji systemu operacyjnego i platformy) dla większości urządzeń Nexus, w tym prawie 3-letniego Nexusa 4. Samsung również poszedł w ich ślady i ogłosił, że będzie współpracować z operatorami i partnerami w celu wdrożenia rozwiązania miesięczny program aktualizacji zabezpieczeń ale nie udało się określić urządzeń i szczegółów harmonogramu tej implementacji. Jest to interesujące, ponieważ wspomina o „szybkim” podejściu do aktualizacji zabezpieczeń we współpracy z operatorami, więc możemy spodziewaj się częstszych aktualizacji (choć opartych na bezpieczeństwie, ale miejmy nadzieję, że przyspieszy to również aktualizacje oprogramowania sprzętowego) u operatora urządzenia.

Inni producenci OEM dołączający do pakietu to LG, z którym dołączy comiesięczne aktualizacje zabezpieczeń. Motorola ogłosiła także lista urządzeń, które zostaną zaktualizowane z poprawkami Stagefright, a lista obejmuje prawie wszystkie urządzenia, które firma wyprodukowała od 2013 roku. Sony również to stwierdziło jego urządzenia wkrótce otrzymają łatki zbyt.

Tym razem przewoźnicy również będą dostarczać aktualizacje. Sprint ma wydał oświadczenie że niektóre urządzenia otrzymały już łatkę Stagefright, a aktualizacja ma mieć więcej urządzeń. AT&T również poszło w ich ślady wydając łatkę na niektóre urządzenia. Verizon również wydał poprawki, aczkolwiek jest to powolne wdrażanie, w którym priorytetem są smartfony z najwyższej półki, takie jak Galaxy S6 Edge i Note 4. T-Mobile Note 4 również otrzymał aktualizację łatki Stagefright.

Jako użytkownik końcowy możesz podjąć kilka kroków zapobiegawczych, aby zmniejszyć ryzyko ataku. Na początek wyłącz automatyczne pobieranie wiadomości MMS w aplikacjach do przesyłania wiadomości dostępnych w telefonie. Powinno to kontrolować przypadki, w których nie była wymagana żadna interakcja użytkownika, aby exploit zadziałał. Następnie uważaj, aby unikać pobierania multimediów z wiadomości MMS z nieznanych i niezaufanych źródeł.

Jako zaawansowany użytkownik XDA również możesz wprowadź zmiany w rekwizycie kompilacji, aby wyłączyć Stagefright. Nie jest to kompletny i pewny sposób na uratowanie się przed Stagefrightem, ale możesz zaryzykować i zmniejszyć prawdopodobieństwo udanego ataku, jeśli utkniesz na starszej wersji Androida. Istnieją również niestandardowe rozwiązania ROM, z których większość regularnie synchronizuje źródła z AOSP, dlatego zawierają poprawki Stagefright. Jeśli używasz ROMu opartego na AOSP, zdecydowanie zaleca się aktualizację do nowszej wersji ROM, która zawiera łatki Stagefright. Możesz użyć ta aplikacja aby sprawdzić, czy Stagefright ma wpływ na Twojego obecnego dziennego kierowcę.

Android, po tremie

Stagefright to nic innego jak pobudka w kierunku Androida i jego problemu fragmentacji oraz aktualizacji. Podkreśla, że ​​nie ma jasnego mechanizmu umożliwiającego terminowe wdrożenie takich krytycznych poprawek na wielu urządzeniach. Chociaż producenci OEM próbują udostępniać łatki dla urządzeń, brutalna prawda jest taka, że ​​większość tych poprawek będzie ograniczona tylko do najnowszych flagowców. Inne statki inne niż flagowe i starsze urządzenia, a tym bardziej mniejsze producentów OEM, będą nadal narażone na działanie podobne do Stagefright.

Ten exploit ma dobre strony: Rzeczywiście ponownie zwrócił uwagę na proces aktualizacji Androida i przedstawił go w świetle, które nie przyciągnie tak wielu przyszłych firm korporacyjnych do przyjęcia Androida do użytku korporacyjnego. W miarę jak Google pracuje nad większym przyjęciem rozwiązań w przedsiębiorstwach, będzie zmuszony ponownie przemyśleć swoją strategię aktualizacji i zakres kontroli, jaką zapewnia producentom OEM.

Ponieważ Android M z dnia na dzień zbliża się do premiery rynkowej, nie byłoby zaskoczeniem, gdyby Google zdecydował się zrezygnować z coraz większej liczby komponentów AOSP na rzecz pakietu usług Play. W końcu jest to obszar, nad którym Google nadal zachowuje pełną kontrolę, jeśli urządzenie ma być dostarczane ze Sklepem Google Play. Ten ma swoje wady w formie zastąpienia obszarów otwartych ścianami pochodzącymi z zamkniętych źródeł.

Spekulując na temat przyszłości Androida, istnieje (bardzo mała) możliwość, że Google może również ograniczyć zmiany, które producenci OEM mogą wprowadzić w AOSP. Z Ramy RRO będąc obecnym w stanie funkcjonalnym w systemie Android M, Google mógłby ograniczyć producentów OEM do wprowadzania jedynie kosmetycznych zmian w postaci skórek RRO. Powinno to umożliwić szybsze wdrażanie aktualizacji, ale odbyłoby się kosztem pozbawienia producentów OEM możliwości pełnego dostosowania systemu Android.

Inną opcją, która może być możliwa, byłoby wprowadzenie obowiązku dla wszystkich wysyłanych urządzeń Sklep Google Play, aby otrzymywać gwarantowane aktualizacje zabezpieczeń przez określony czas, ewentualnie dwa lata. Platforma Usług Play może zostać wykorzystana do sprawdzenia obecności ważnych aktualizacji i poprawek zabezpieczeń, a w przypadku nieprzestrzegania zasad dostęp do Sklepu Play może zostać zablokowany.

Uwagi końcowe

To w najlepszym razie spekulacja, ponieważ nie ma eleganckiego sposobu na rozwiązanie tego problemu. Poza bardzo totalitarnym podejściem, zawsze będą pewne niedociągnięcia w zasięgu poprawek. Ze względu na ogromną liczbę urządzeń z Androidem śledzenie stanu zabezpieczeń każdego urządzenia byłoby bardzo gigantycznym zadaniem. Potrzebą chwili jest ponowne przemyślenie sposobu aktualizacji Androida, ponieważ obecny sposób z pewnością nie jest najlepszy. W XDA Developers mamy nadzieję, że Android nadal pozostanie wierny swoim korzeniom Open Source, współpracując z planami Google dotyczącymi zamkniętego oprogramowania.

Czy Twój telefon jest podatny na Stagefright? Czy myślisz, że Twój telefon kiedykolwiek otrzyma łatkę Stagefright? Daj nam znać w komentarzach poniżej!