FlawOpen

flawopen.com/Teardowns/cve-2026-65995-osmand-aidl-authorization

● CVE-2026-65995 · Высокий
Исследования · FlawOpen

CVE-2026-65995: обход авторизации AIDL в OsmAnd

OsmAnd 5.3.3 автоматически одобрял неизвестных вызывающих через экспортированную службу Android AIDL, открывая доступ к местоположению и файловым операциям любому уже установленному приложению. В advisory подтверждено исправление, но не указаны первая исправленная версия и оценка CVSS.

💡 Простыми словами (ELI5)

Представьте администратора здания, который должен сверяться со списком гостей, но сразу добавляет каждого нового посетителя в список одобренных. Служба OsmAnd делала похожее с приложениями на том же телефоне: записывала неизвестных вызывающих как разрешённых и открывала им интерфейс интеграции. Исправление должно требовать явного согласия и связывать его с подлинной Android-идентичностью вызывающего.

Ключевые понятия и термины

AIDL
Android Interface Definition Language: механизм вызова одним процессом Android методов другого процесса через Binder IPC.
Экспортированная служба
Служба Android, к которой могут подключаться другие приложения. Чувствительные методы должны защищаться разрешением или равноценной проверкой вызывающего.
UID вызывающего
Идентификатор процесса приложения, назначенный ОС. Служба должна получать его от Binder, а не доверять имени пакета из запроса.
CWE-862
Редакционная классификация FlawOpen для отсутствующей общей проверки авторизации. GHSL указывает CWE-862 среди нескольких слабостей; оценка CVSS в advisory не опубликована.

Связи со стандартами

  • Концептуальное соответствие FlawOpen для MITRE CWE; ни поставщик, ни запись CVE не присваивали этот идентификатор слабого места данной исследовательской демонстрации. CWE-862

Анализ первопричины

GitHub Security Lab проверила OsmAnd 5.3.3 и обнаружила, что экспортированная OsmandAidlServiceV2 не требовала разрешения Android, а OsmandAidlApi.isAppEnabled() создавала неизвестный ConnectedApp с enabled=true. Поскольку getApi() допускала вызовы AIDL на основании этой проверки, новое локальное приложение сохранялось как авторизованное вместо отказа до согласия пользователя. По данным GHSL, это открывало 97 методов AIDL, включая методы возврата данных о местоположении/навигации и файловые операции с проблемами обхода пути. Злоумышленнику нужно заранее установить приложение на то же устройство, но этому приложению не требуются разрешение на геолокацию или дополнительное действие пользователя. Описанные GHSL действия с файлами ограничены хранилищем OsmAnd, а не всей файловой системой устройства. Разработчики подтвердили исправления 28 июня 2026 года, но advisory не указывает первую исправленную версию. CVSS не опубликован; FlawOpen редакционно оценивает серьёзность как высокую, поскольку общая проверка открывала данные местоположения и операции, влияющие на целостность. CWE-862 — основная редакционная классификация FlawOpen, а не единственная категория, присвоенная GHSL.

Пошаговый сценарий атаки

Шаг 1

Локальное приложение подключается к экспортированной службе

Уязвимая служба была экспортирована без разрешения Android. Установленное на устройстве приложение могло подключиться, не запрашивая разрешение OsmAnd на местоположение.

Шаг 2

Проверка сама создаёт разрешение

Для неизвестного пакета isAppEnabled() создавала и сохраняла ConnectedApp с enabled=true. Проверка выдавала доступ, который должна была проверять.

Шаг 3

Общая проверка открывает множество функций

getApi() использовала результат для обработки вызовов AIDL. По данным GHSL, путь охватывал 97 методов, включая getAppInfo() и операции копирования файлов.

Шаг 4

Последствия ограничены подтверждёнными условиями

Вредоносное приложение должно быть уже установлено на устройстве. GHSL описывает раскрытие данных местоположения/навигации и изменения файлов в хранилище OsmAnd; доступ ко всему устройству или реальная эксплуатация у клиентов не подтверждены.

Исходный код: Уязвимый vs Защищённый вариант

Уязвимый фрагмент приведён из анализа GHSL для проверенной версии 5.3.3. Нижний пример — минимальная схема политики fail-closed, а не патч OsmAnd и не полная реализация: процесс одобрения должен проверять UID, подпись установленного пакета, согласие пользователя и полномочия для каждого метода. Производственная служба должна применять авторизацию на границе Binder и отдельно ограничивать чувствительные методы. GHSL подтвердил исправление, но не опубликовал полный diff и первую исправленную версию; установите поддерживаемый выпуск и проверьте актуальные указания производителя. Код учебный, не содержит эксплойта или данных местоположения/файлов.

Фрагмент исходного кода: Метод: isAppEnabled()

УЯЗВИМАЯ РЕАЛИЗАЦИЯ
public boolean isAppEnabled(@NonNull String pack) {
    ConnectedApp connectedApp = connectedApps.get(pack);
    if (connectedApp == null) {
        connectedApp = new ConnectedApp(app, pack, true);
        connectedApps.put(pack, connectedApp);
        saveConnectedApps();
    }
    return connectedApp.isEnabled();
}
БЕЗОПАСНЫЙ ИСПРАВЛЕННЫЙ ВАРИАНТ
private final Set<Integer> approvedCallerUids = new HashSet<>();

private boolean isAppEnabled() {
    // Заполняйте поле только после явного согласия пользователя и проверки его личности.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Чек-лист по защите системы для инженеров

Источники