Неправильно сформований WAP Push SMS без кліку аварійно завершує роботу телефонії Android

Неправильно сформований WAP Push SMS може віддалено аварійно завершувати роботу com.android.phone на Android без дій користувача, повідомляє незалежний дослідник Mark Blaszczyk. Аварійне завершення може обривати активні виклики, зокрема екстрені, а повторна доставка може пошкодити сховище SMS і зробити пристрій постійно непридатним. Google після розгляду класифікувала цю проблему як не пов'язану з безпекою.

Технічна причина

Коли Android отримує повідомлення WAP Push, WapPushOverSms.decodeWapPdu() читає довжину заголовка WSP як uintvar. Значення повертається як long, приводиться до int без перевірки діапазону і використовується як розмір нового масиву байтів. 5-байтовий uintvar зі значеннями 88 80 80 80 00 декодується як 0x80000000, що стає -2147483648 як знакове 32-бітне int. Виділення new byte[-2147483648] викидає неперехоплене NegativeArraySizeException у головному потоці телефонії, що завершує роботу com.android.phone. Повідомлення доставляється як SMS даних і не показується користувачу.

Наслідки та відновлення

Повідомлення працює без кліку і безшумно. У Messages нічого не з'являється, а номер відправника не показується. Виклики обриваються, зокрема екстрені, а активні голосові виклики завершуються під час перезапуску процесу. Телефонія недоступна приблизно від 1 до 2 секунд на одне повідомлення, поки com.android.phone перезапускається. Повторна доставка оператором може повторювати аварію; в тестуванні одне повідомлення спричиняло періодичні відключення до тижня, а приблизно 20 повідомлень робили пристрій непридатним протягом тривалого часу. Швидка повторна доставка може пошкодити базу даних SQLite за сховищем SMS, через що com.android.phone аварійно завершується при кожному завантаженні. Відновлення вимагало перенесення фізичної SIM у пристрій не на Android, щоб повторні повідомлення були підтверджені, а потім очищення записів SMS через ADB. З eSIM відновлення було б значно складнішим.

У звіті сказано, що пристрій під час такої атаки не може надійно викликати 000. Він посилається на обов'язки австралійських операторів за Telecommunications (Emergency Call Service) Determination, яке адмініструє ACMA, і зазначає, що Telstra заявляє про обов'язок блокувати телефони, які більше не можуть викликати 000, із повідомленням клієнта та блокуванням пристрою, якщо протягом 28 днів нічого не буде зроблено.

Розкриття та статус

Mark Blaszczyk подав звіт 5 травня 2026 року через Android and Google Devices VRP і двічі повторно надіслав його як апеляцію щодо помилкового тріажу. Google взяла його до розгляду, закрила як Won't Fix (Infeasible) 20 червня 2026 року, закрила повторне подання як Won't Fix (Not Reproducible) упродовж трьох хвилин, а 29 жовтня 2026 року ухвалила остаточне рішення Won't Fix, цитуючи, що це не відповідає порогу серйозності й вважається Non-Security Issue (NSI). У розкритті сказано, що його утримували понад 90-денне вікно VRP.

Запропоноване виправлення полягає в перевірці діапазону перед приведенням типу у WapPushOverSms.java: прочитати значення як long, відхилити значення менші за 0 або більші за pdu.length, повернути результат помилки, а потім привести до int. Доказ концепції та вихідний код опубліковані на GitHub; попередження каже, що це лише для авторизованого тестування.

Джерела: smsofdeath.com