LSPromise превращает обычное Android-приложение в хозяина ядра

LSPromise превращает обычное Android-приложение в хозяина ядра

LSPromise превращает обычное Android-приложение в хозяина ядра

Исследователи опубликовали цепочку эксплойтов LSPromise, позволяющую недоверенному локальному приложению получить полный контроль над ядром устройства. Атака затрагивает как минимум первоначальный релиз Android 17, а её техническое описание и PoC-код уже выложены в открытый доступ.

Отличный момент проверить обновления, пока эксперимент не превратился в готовый инструмент злоумышленников.

Цепочка объединяет три уязвимости: CVE-2026-49881, CVE-2026-43284 и CVE-2026-43500. Максимальный балл по CVSS достигает 8,8 балла из 10.

Исследователи успешно проверили атаку на Pixel 10 с первой официальной версией Android 17 и заявили о стопроцентной надёжности эксплойта в уязвимой конфигурации. На Pixel 6a цепочка не сработала.

Первым звеном становится логическая ошибка в системном сервисе Telecom. Она позволяет вредоносному приложению добиться выполнения кода внутри привилегированного процесса system_server. Затем атакующие обходят ограничения SELinux, переносят выполнение в сетевой процесс и задействуют уязвимость DirtyFrag в ядре Linux.


Финал у этой прогулки по уровням защиты невесёлый: загрузка постороннего модуля ядра, перевод SELinux в разрешающий режим и полный root-доступ. Причём цепочка не зависит от традиционных методов повреждения памяти и обходит такие механизмы защиты, как KASLR и MTE.

Компонент DirtyFrag может затрагивать и другие устройства, использующие ветки ядра 6.1.xxx-android14, однако полного списка уязвимых моделей пока нет. Случаи применения LSPromise в реальных атаках также не подтверждены.

Пользователям рекомендуют установить свежие патчи производителя: других способов надёжно оборвать атаку сейчас не предлагается.

MAX Desktop проверили на слежку за VPN, сенсация не состоялась

Пользователь Хабра Slava_B протестировал поведение десктопного клиента MAX в Windows и не обнаружил признаков того, что мессенджер распознаёт VPN при маршрутизации трафика через роутер. Зато приложение читает ряд системных параметров и идентификаторов компьютера.

Эксперимент провели 8 сентября 2026 года. Windows-компьютер подключили к роутеру Keenetic, который самостоятельно распределял трафик: российские ресурсы открывались напрямую, а часть остальных соединений уходила через OpenConnect-туннель на европейский VPS.

В самой Windows не было ни VPN-клиента, ни виртуального адаптера, ни соответствующих маршрутов.

За клиентом MAX следили с помощью Process Monitor, Wireshark и TCPView, а трафик на удалённом сервере записывали через tcpdump. Исследователь выяснил, что приложение запускает процессы MAX.exe и MAX-service.exe, связывающиеся между собой через локальный порт. Клиент подключался к инфраструктуре MAX/ONEME, сервису AppTracer и системам для звонков.


MAX и его служебный процесс многократно читали MachineGuid — стабильный идентификатор установки Windows. Программа также получала имя компьютера, настройки proxy/PAC, собственные device ID и сведения о микрофонах и камере. Впрочем, подобные данные могут использоваться для диагностики, антифрода, подключения через корпоративный прокси и работы звонков.


Главный результат успокаивает: соединения MAX не появились на VPN-интерфейсе VPS, а обращений к сервисам определения внешнего IP, Telegram, WhatsApp (принадлежит корпорации Meta, признанной экстремисткой и запрещённой в России) или другим ресурсам для проверки маршрута исследователь не выявил. Браузеры клиент тоже не запускал.

При этом автор подчёркивает: содержимое TLS-трафика не расшифровывалось, поэтому доказательств передачи MachineGuid или других идентификаторов на сервер нет. Результат относится только к конкретной конфигурации и не показывает, как MAX поведёт себя с VPN-клиентом непосредственно в Windows.

RSS: Новости на портале Anti-Malware.ru