Przejdź do treści

SMS of Death: jeden niewidoczny SMS potrafił zawiesić telefon z Androidem. Załatano to w październiku

Adam Marzec
Karta luki SMS of Death w Androidzie: trzy białe karty z wektorem data SMS na port 2948, pętlą restartów co 90 sekund i poprawką z października 2026; pieczątka POZIOM POPRAWEK; nagłówek SMS OF DEATH TELEFON BEZ DOTYKU; odczyty 29.10.2026

We wtorek 29 października badacz chowający się za inicjałami „Mark B” opublikował pełny opis luki, którą zgłosił Google 5 maja tego roku. Mechanizm brzmi absurdalnie prosto: jedna źle zbudowana wiadomość typu WAP Push, wysłana jako data SMS na port 2948, wywala proces com.android.phone na telefonie ofiary. Bez dotknięcia ekranu, bez powiadomienia, bez śladu w skrzynce SMS. Wątek na Hacker News zebrał 299 punktów, a strona opisująca lukę nosi nazwę, która zostanie już zapewne na stałe: SMS of Death. Najważniejsze dla zwykłego użytkownika jest to, że Google wypuściło łatkę w comiesięcznej aktualizacji zabezpieczeń Androida za październik 2026, więc dziś to bardziej lekcja o aktualizowaniu telefonu niż alarm.

Najważniejsze informacje

CoSzczegóły
KomponentWapPushOverSms w frameworks/opt/telephony, proces com.android.phone
WektorData SMS z ładunkiem WAP Push na port 2948, wystarczy znać numer ofiary
Interakcja ofiaryZero: wiadomość nie pojawia się w skrzynce, numer nadawcy niewidoczny
SkutkiPad aktywnej rozmowy (w tym awaryjnej), 1-2 s bez zasięgu na wiadomość, po ok. 20 wiadomościach telefon bezużyteczny
Pętla restartówTrucizna siedzi w kolejce i jest ponawiana przy każdym uruchomieniu; RescueParty wypycha do recovery co ok. 90 s
Zgłoszenie i łatka5.05.2026 do Android & Devices VRP; commit 735d967 z 15.06.2026; aktualizacja zabezpieczeń z października 2026 (Android 14-17)
CVEBrak przydzielonego numeru

Jak jeden błąd rzutowania kładzie cały telefon

Gdy Android dostaje wiadomość WAP Push, funkcja decodeWapPdu w WapPushOverSms czyta długość nagłówka w formacie uintvar, który potrafi zakodować bardzo duże liczby na pięciu bajtach. Wartość wraca jako long, po czym trafia do rzutowania na int bez jakiegokolwiek sprawdzenia zakresu, a potem służy jako rozmiar nowej tablicy bajtów. Konkretny ładunek z writeupu dekoduje się do 0x80000000, co w rzutowaniu na liczbę ze znakiem daje minus 2147483648. Próba utworzenia tablicy o ujemnym rozmiarze rzuca NegativeArraySizeException na głównym wątku telefonicznym i cały proces com.android.phone umiera, a razem z nim padają aktywne rozmowy, łącznie z tymi do numerów awaryjnych.

To jedna z najstarszych klas błędów w C i Javie, niesprawdzone rzutowanie, siedząca w kodzie, który obsługuje technologię z początku lat dwutysięcznych. WAP Push to relikt ery dzwonków i linków konfiguracyjnych od operatorów, ale jego obsługa siedzi w podsystemie telefonicznym Androida do dziś, a wiadomość tego typu idzie przez sieć komórkową jak zwykły SMS, więc nie ma zapory ani antywirusa, który by ją wyłapał. Autor testował Pixela 9 na firmware z kwietnia 2026 oraz różne Samsungi z serii Galaxy i A, z pełną skutecznością reprodukcji.

Co się działo z zaatakowanym telefonem

Pojedyncza wiadomość kosztowała 1-2 sekundy całkowitego braku sieci, bo proces telefoniczny restartuje się i nabiera stanu. Ale naprawa poczty nie jest tu wolna: niepotwierdzona wiadomość zostaje w kolejce i operator wysyła ją ponownie, co po kolei wywala telefon raz za razem. W testach autora jedna wiadomość potrafiła generować przestoje przez tydzień, a około 20 sztuk czyniło urządzenie bezużytecznym na dłuższy czas. Gorzej jeszcze: trucizna siedzi w tabeli nieprzetworzonych wiadomości (content://sms/raw) i jest ponawiana przy każdym uruchomieniu, więc telefon potrafił wpadać w pętlę restartów, a mechanizm RescueParty wypychał go do trybu recovery co jakieś 90 sekund. Zwykły użytkownik, który nie ma pojęcia o ADB, skończyłby na przywracaniu ustawień fabrycznych.

Odzyskanie bez utraty danych jest możliwe i ktoś z komentarzy (@sakisdog) opisał procedurę: z komputera po ADB w krótkim oknie po uruchomieniu usuwa się z tabeli content://sms/raw tylko wiersze z portem docelowym 134020 (0x2948) przy zadanym numerze nadawcy. Ostateczność to wyczyszczenie com.android.providers.telephony, co kasuje wszystkie SMS, MMS i ustawienia APN. W dokumencie pojawia się też ostrzeżenie, które warto przepisać: przy monicie recovery nie wybieramy „wipe data”.

Łatka: nie to, co badacz zaproponował

Mark B podał Google poprawkę pierwszego dnia zgłoszenia: sprawdzenie zakresu przed rzutowaniem, trzy linijki. Google naprawiło problem w czerwcu (commit 735d967, „Fix remote DoS in decodeWapPdu”, 15.06.2026), ale innym sposobem: poszerzyło klauzulę przechwytywania wyjątków, żeby NegativeArraySizeException został połyknięty zamiast zabijać proces, i dołożyło kasowanie niepoprawnej wiadomości z tabeli, co łamie pętlę restartów. Technicznie to obojętne dla bezpieczeństwa: trudna wiadomość już nie kładzie telefonu. Komentarze inżynierskie przy takim rozwiązaniu bywają różne, bo łapanie RuntimeException to metoda zaporowa, a nie eliminacja przyczyny, ale efekt jest trwały i przyjdzie z resztą październikowej aktualizacji zabezpieczeń dla Androida 14-17.

Co z tym zrobić dziś, w Polsce

Krok jest jeden: sprawdzić poziom poprawek zabezpieczeń. W Ustawieniach, najczęściej w Informacji o telefonie, siedzi pozycja „Poziom poprawek zabezpieczeń Androida”; jeśli data jest z października 2026 albo nowsza, telefon jest chroniony. Starsze poziomy pozostają podatne, dopóki producent nie roześle własnej aktualizacji, co w świecie Samsungów i Xiaomi bywa kwestią tygodni. Warto dodać, że strona writeupu siedzi w australijskim kontekście (autor pisze o numerach awaryjnych Triple Zero i regulacji ACMA), ale sama luka dotyczy każdego Androida 14-17, a u nas pytanie sprowadza się do tych samych dwóch rzeczy: czy proces telefoniczny dostał łatkę i czy numer 112 byłby osiągalny w trakcie ataku. Polskich doniesień o wykorzystaniu luki nie ma w odczytach z 29.10, a sama strona ostrzega wprost, że opublikowany kod to działająca broń i że używanie jej na cudzych urządzeniach jest przestępstwem w Australii i w większości krajów.

Dla dociekliwych luka jest ciekawym kontrapunktem dla niedawnej fali błędów w łańcuchach dostaw oprogramowania, o których pisaliśmy przy PHP2Shell; tam chodziło o serwery, tu o telefon w kieszeni. Rodzina fraz „telefon sam się wyłącza i włącza” pokazuje przy okazji, jak częstym tematem jest zwykła diagnostyka restartów, więc zanim zaczniecie podejrzewać egzotyczne luki, sprawdźcie poziom poprawek i dopiero potem szukajcie dalszych przyczyn.

Najczęstsze pytania

Telefon sam się wyłącza i włącza, czy to ten błąd?

Możliwy, ale mało prawdopodobny. Symptom pętli restartów po SMS of Death to uruchomienie, krótki crash i powrót do recovery co ok. 90 sekund, zwykle po otrzymaniu wiadomości z konkretnego numeru. Zwykłe losowe restarty mają najczęściej powody w baterii, przegrzaniu albo aplikacji; zacznijcie od poziomu poprawek zabezpieczeń i od listy ostatnich SMS.

Jaki poziom poprawek zabezpieczeń Androida jest bezpieczny?

Październik 2026 albo nowszy. Łatka (commit 735d967) weszła do comiesięcznej aktualizacji zabezpieczeń za październik 2026 dla Androida 14-17. Data siedzi w Ustawieniach, w Informacji o telefonie, pod pozycją „Poziom poprawek zabezpieczeń Androida”.

Czy zwykły SMS może zawiesić telefon?

Nie ten zwykły, tekstowy. Tu chodziło o data SMS z ładunkiem WAP Push na port 2948, specjalnie zbudowany tak, by zmusić Androida do rzutowania 0x80000000 na rozmiar tablicy. Wiadomość nie pojawiała się w skrzynce, więc ofiara nie widziała nawet numeru nadawcy.

Co to jest WAP Push?

Stara usługa z początku lat dwutysięcznych, którą operatorzy wysyłali ustawienia, dzwonki i linki prosto do telefonu. Obsługa siedzi w podsystemie telefonicznym Androida do dziś, choć same wiadomości to już relikt; właśnie dlatego luka w jej obsłudze dotyczyła współczesnych wersji systemu.

Źródła

Powiązane artykuły