"...маленькая ошибка в коде Android разрушила иллюзию приватности"

https://www.securitylab.ru/news/572456.php

Надо быть сказочным долбоебом, чтобы называть ошибкой то, что Google оставил себе и товарищам такой канал эксфильтрации. Очень удобный и продуманный канал.

Суть: Android 16 представил оптимизацию registerQuicConnectionClosePayload в ConnectivityManager. Любое приложение с разрешениями INTERNET + ACCESS_NETWORK_STATE регистрирует через этот API произвольный UDP-payload в system_server. При закрытии socket'а приложения, system_server сам отправляет зарегистрированный пакет данных наружу. Поскольку отправка идёт от system_server'а, а он вполне себе привилегированная сущность, все это не подпадает под Always-on VPN + Block connections without VPN - стандартные опции. Реальный публичный IP устройства утекает на сервер атакующего, минуя VPN.

Проверить на уязвимость можно так:

su -c 'dumpsys connectivity' | grep -iE 'quic|close_quic'

true - всратая оптимизация активна, устройство потенциально уязвимо.
Registered QUIC connection close information: 0 - счетчик зарегистрированных payload'ов в текущий момент времени, нулевое значение нифига не отменяет уязвимости, только показывает в реальном времени: никто не подсосался к system_server.

Почему Google не хочет это фиксить? Ну, во-первых, не для того встраивали, чтобы убирать. Это не оптимизация QUIC close, а "отправь от моего имени из system_server что я тебе скажу". Ни один безопасник в здравом уме такого не допустит. GrapheneOS пофиксили это отключением единственного флага, и если бы это был банальный косяк разрабов - ничего не мешает вырубить флаг в последующих сборках AOSP. Но Google заявил принципиальный Won't Fix.

А во-вторых QUIC (UDP) активно используется Chrome, YouTube, Gmail, Google Maps через Cronet (network library от Google) и вот это все. Вся инфраструктура Gapps'ов сидит на этом. Убрать данный API - ушатать все к хренам, потом все долго и дорого переделывать и, главное, потерять для себя и партнеров один из каналов network identity tracking, да еще и оплатить из своего кармана. Это не бизнес модель ad networks, частью которой являются гуглы, фэйсбуки и прочие продаваны всех и каждого.

А теперь, мои маленькие рутованные друзья, придвиньтесь поближе. Нерутованные идите к графенам, они вам героически пофиксят что-нибудь.

Утечка происходит только потому, что system_server физически отправляет UDP-packet наружу через сетевой интерфейс. Когда пофиг какой/любой процесс на Android отправляет данные в сеть, kernel (ядро) запоминает "от чьего имени" этот packet, записывает UID процесса-отправителя. Это как штамп на конверте: отправлено от UID 1000 (именно такой UID будет иметь system_server на любом Android, это костанта).

Дальше пакет идёт через netfilter, который в большинстве случаев - это iptables, следовательно REJECT на UID 1000 - это ваш kill switch, а не то что там Google для нубасов нарисовал.

Есть гипотетическая вероятность что Google встроит BPF-bypass для системных UID в будущем, но это будет вот прям архитектурный сдвиг, который не пройдет незамеченным Android-сообществом и тем более не перекочует в кастомы типа LOS, crDroid и тд. В общем, не бойтесь Root. Он, в отличие от Google, вам друг и помощник.