ч1: Обзор. Полгода после утечки через tun0. Кто из VPN-клиентов закрыл дыру, а кто закрыл issue

[Melgibzen]

в v2rayNG утечка через tun0 давно пофикшена (#5457), но нужна настройка

[LuciusWill]

Благодарю за информацию 👍

[Ilnurathome]

Про orbot не понял. Это же Tor, там exit узлы и так в публичном списке, нет?

[Diaboliko]

Но профили Android разделяют данные и аккаунты

Не могли бы вы раскрыть этот тезис? В моём понимании рабочие профили как раз изолированы by design. Какие-то вещи наследуются от админа, вроде базовой сети, но, в целом, я верю что хранить мутные приложения на отдельном профиле достаточно

[LuciusWill]

Не совсем так. Рабочие профили (Work Profile), Shelter, Island и обычные secondary user profiles действительно изолируют данные и аккаунты. Это сделано by design на уровне Android Framework:

• У каждого профиля свой /data/user/<userId>/

• Свои аккаунты (AccountManager)

• Свои контакты, медиа, SharedPreferences, databases

• В случае Managed Profile ещё и отдельные политики Device Policy Controller

То есть приложение из одного профиля физически не может прочитать файлы другого. Это правда.

Но сеть — это совсем другая история.

Все профили на одном устройстве живут в одном сетевом пространстве ядра. Нет никакого network namespace per profile (в отличие от, например, полноценных контейнеров или user namespaces с netns). Когда VPN-клиент в основном профиле поднимает tun0 (или tun1), этот интерфейс появляется в общем сетевом стеке. И любое приложение, даже из другого профиля, может:

1. Узнать о существовании интерфейса (через /sys/class/net, if_nameindex, или просто перебором tun0/tun1/tun2 — имена стандартные).

2. Сделать setsockopt(socket, SOL_SOCKET, SO_BINDTODEVICE, "tun0").

3. Отправить пакет, который ядро честно отправит в этот интерфейс, потому что для SO_BINDTODEVICE маршрут по UID уже не играет роли — пакет принудительно уходит в указанный девайс.

Именно поэтому RKNHardering (и любой другой код, который делает то же самое) спокойно находит tun0 изнутри Shelter. Мы это проверяли.

«Какие-то вещи наследуются, вроде базовой сети» — это не «какие-то», это вся сетевая подсистема. Wi-Fi, мобильная сеть, VPN-туннели, маршруты — всё общее. Изоляция профилей заканчивается на уровне файловой системы, процессов и аккаунтов. Сетевой стек один.

Отсюда практический вывод:

Хранить «мутные» приложения в отдельном профиле — хорошая гигиена с точки зрения данных и аккаунтов. Но это не защита от утечки адреса VPN-сервера через привязку к tun0. Эта конкретная дыра закрывается только на стороне VPN-клиента: он должен смотреть, чей UID пытается отправить пакет в туннель, и чужие отбрасывать. Никакой профиль, Shelter или Island этого за него не сделает.

Так что тезис «профили разделяют данные и аккаунты» — буквально про то, что изоляция данных есть, а изоляции сети нет. Именно поэтому совет «просто кинь приложение в рабочий профиль» от этой конкретной атаки не спасает.

[litalen]

1. В тексте вы неоднократно упоминаете Exclave, а ни в одной таблице его нет. Уж вспомните про него наконец полностью и впишите как пофикшенный :)

2. Фикс - не обязательно тайм-аут, у Exclave один мой друг поставил так, что UID -1 - это вердикт “Bypass” а не “Block”, т.е. curl возвращает “обычный” IP для неразрешенного приложения, а не тайм-аут.