ИИтог

Google может заблокировать локальный ADB-доступ на Android

безопасностьРедакция ИИтогHacker News🔥69Рейтинг ИИтог · значимость 55 · 221 баллов · 74/ч · 107 коммент.

На Google Issue Tracker появился запрос о том, чтобы разработчики могли выбирать, на каком сетевом интерфейсе слушает демон ADBD (серверный демон ADB). Один из основных разработчиков ADB, сотрудник Google, в комментарии предложил разрешить привязку демона только к интерфейсу Wi-Fi (wlan0). Поводом стала уязвимость CVE-2026-0073, из-за которой можно было полностью обойти проверку подлинности при беспроводном ADB-подключении.

Если предложение реализуют буквально, пострадает так называемый on-device ADB, практика, когда клиент и сервер ADB работают на одном и том же телефоне через loopback-адрес (127.0.0.1). Такой режим не является официальной функцией ADB, но на нём построена целая экосистема инструментов для энтузиастов и разработчиков без второго компьютера: Shizuku, libadb-android, App Manager, Canta, aShell, ShizuWall и другие, включая приложение автора поста ShizuCallRecorder, запись звонков для людей с ограниченными возможностями.

Автор, разработчик под ником Kitsumed, подчёркивает, что это ещё не официальное объявление Google, а лишь один комментарий в обсуждении, и просит сообщество не спамить трекер грубыми жалобами ("мне нужен Shizuku!"), а вместо этого либо оставлять конструктивную обратную связь с описанием сценариев использования, либо просто ставить +1 к уже существующим комментариям.

Основной аргумент поста: on-device ADB нельзя тайно включить силами вредоносного приложения. Автор разбирает три сценария. У обычного пользователя ADB по умолчанию выключен, и без ручного включения через настройки атака невозможна. У разработчика с включённой беспроводной отладкой приложению всё равно нужен одноразовый код сопряжения, который вручную выдаёт пользователь. При ADB через TCP/IP любое новое подключение требует подтверждения на экране, если пользователь нажмёт "Нет", соединение будет отклонено. То есть даже в сценарии, похожем на CVE-2026-0073, эксплуатация возможна только после того, как пользователь сам вручную включил отладку по USB (а для TCP/IP, ещё и вручную включил этот режим).

Автор предлагает альтернативу полной блокировке: сделать защиту опцией, которую можно постоянно (переживающей перезагрузку) отключить в настройках, а не запрещённой навсегда, по аналогии с тем, что пользователь и так может вручную выдать приложению права администратора устройства или доступ Accessibility, и эти функции никто не отключает целиком.

Ключевые факты

  • На Google Issue Tracker обсуждают предложение ограничить ADBD только интерфейсом Wi-Fi (wlan0), повод: уязвимость CVE-2026-0073, полностью обходившая проверку подлинности беспроводного ADB.
  • Под угрозой on-device ADB, режим, когда клиент и сервер ADB работают на одном телефоне через loopback (127.0.0.1); на нём построены Shizuku, libadb-android, App Manager, Canta, aShell, ShizuWall и другие инструменты.
  • Автор поста, разработчик ShizuCallRecorder (запись звонков для людей с ограниченными возможностями), сам пострадает от изменения и объясняет, почему считает его избыточным.
  • По разбору трёх сценариев автора, вредоносное приложение не может само включить или использовать on-device ADB без ручных действий пользователя (включение отладки, ввод кода сопряжения, подтверждение подключения на экране).
  • Предложение автора, не блокировать функцию навсегда, а сделать защиту переключаемой в настройках, переживающей перезагрузку; сообщество приглашают оставлять конструктивную обратную связь в трекере, а не спамить его.

Почему это важно

Google рассматривает изменение поведения ADB (Android Debug Bridge), базового инструмента отладки, которым пользуются миллионы Android-разработчиков и энтузиастов. Повод серьёзный: реальная уязвимость CVE-2026-0073, позволявшая полностью обойти проверку подлинности беспроводного ADB-подключения. Но обсуждаемое решение, привязать демон ADBD только к Wi-Fi-интерфейсу, задевает не только уязвимый сценарий, а вообще все loopback-подключения на самом устройстве, включая легитимные.

Кому это важно

В первую очередь, разработчикам и power-юзерам, которые используют Termux и подобные терминальные эмуляторы для запуска ADB-клиента прямо на телефоне без второго компьютера. Также это касается пользователей приложений на базе Shizuku (расширенный доступ без root) и людей с ограниченными возможностями, которым такие приложения, как ShizuCallRecorder, облегчают повседневные задачи вроде записи звонков.

Как это применить

Пока это не официальное решение Google, а один комментарий разработчика ADB в обсуждении фичи на трекере багов. Тем, кого это касается, автор поста советует не спамить трекер эмоциональными жалобами, а либо описать конкретный сценарий использования и предложить техническое решение/компромисс, либо просто поставить +1 к уже озвученным аргументам и включить уведомления об обновлениях по теме.

Можно ли доверять

Источник, блог независимого разработчика (автора Shizuku-приложения ShizuCallRecorder), не официальный анонс Google. Сам автор явно предупреждает: это не подтверждённое решение, а реакция на комментарий одного сотрудника Google в обсуждении на Issue Tracker, и итоговое поведение Google может отличаться.

Риски и подводные камни

Если Google реализует ограничение буквально (привязка только к wlan0), под удар попадут не только уязвимые сценарии, но и легитимные: ADB через VPN, через Ethernet, on-device ADB через Termux и вся экосистема Shizuku-инструментов. Автор предупреждает, что чрезмерно грубая блокировка функции без настраиваемого переключателя сломает рабочие процессы разработчиков и power-юзеров, которые и так вручную и осознанно включают отладку.

«Подключение к localhost также было источником эксплойтов, когда приложения использовали этот сокет к adbd для повышения своих привилегий. Что если мы ограничим привязку всегда только интерфейсом Wi-Fi wlan0?»

— один из основных разработчиков ADB, сотрудник Google, в комментарии на Google Issue Tracker