CVE-2026-65995: omisión de autorización AIDL en OsmAnd

OsmAnd 5.3.3 aprobaba automáticamente a interlocutores desconocidos en un servicio Android AIDL exportado, exponiendo ubicación y operaciones de archivos a cualquier app instalada en el dispositivo. El aviso confirma una corrección, pero no indica la primera versión corregida ni una puntuación CVSS.

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina la recepción de un edificio que debería consultar una lista de invitados, pero añade a cada visitante nuevo a la lista de aprobados en cuanto llega. El servicio de OsmAnd hacía algo parecido con las apps del mismo teléfono: registraba a los interlocutores desconocidos como habilitados y después les abría la interfaz de integración. La corrección debe exigir aprobación explícita y vincularla con la identidad Android real del interlocutor.

Conceptos Clave y Términos

AIDL: Android Interface Definition Language: mecanismo para que un proceso Android invoque métodos expuestos por otro proceso mediante Binder IPC.
Servicio exportado: Servicio Android al que pueden conectarse otras apps. Los métodos sensibles deben protegerse con un permiso o una comprobación equivalente del interlocutor.
UID del interlocutor: Identidad del proceso de la app asignada por el sistema operativo. El servicio debe obtenerla de Binder, no confiar en un nombre de paquete proporcionado por quien llama.
CWE-862: Clasificación editorial de FlawOpen para el límite de autorización ausente. GHSL incluye CWE-862 entre varias debilidades; el aviso no publica una puntuación CVSS.

Mapeos de marcos

Mapeo conceptual de FlawOpen a MITRE CWE; ningún proveedor ni registro CVE asignó este identificador de debilidad a esta demostración de investigación. CWE-862

Análisis de Causa Raíz

GitHub Security Lab probó OsmAnd 5.3.3 y descubrió que OsmandAidlServiceV2 estaba exportado sin permiso Android y que OsmandAidlApi.isAppEnabled() creaba un ConnectedApp desconocido con enabled=true. Como getApi() condicionaba las llamadas AIDL a esa comprobación, una app local nueva se guardaba como autorizada en vez de denegarse hasta que el usuario la aprobara. GHSL afirma que esto exponía 97 métodos AIDL, incluidos métodos que devuelven datos de ubicación/navegación y operaciones de archivos con fallos de path traversal. El atacante debe tener una app instalada en el mismo dispositivo, pero esa app no necesita permiso de ubicación ni otra acción del usuario. Los efectos en archivos descritos por GHSL se limitan al sandbox de almacenamiento de OsmAnd, no a todo el sistema de archivos del dispositivo. Los mantenedores confirmaron las correcciones el 28-06-2026, pero el aviso no identifica la primera versión corregida. No se publica una puntuación CVSS; FlawOpen asigna severidad Alta editorialmente porque el control compartido exponía ubicación sensible y operaciones que afectan a la integridad. CWE-862 es el mapeo editorial principal de FlawOpen, no una clasificación exclusiva asignada por GHSL.

Flujo de Ataque Paso a Paso

Paso 1

Una app local alcanza el servicio exportado

El servicio vulnerable estaba exportado sin permiso Android. Una app instalada en el mismo dispositivo podía conectarse sin solicitar el permiso de ubicación de OsmAnd.

Paso 2

La comprobación crea la aprobación

Para un paquete desconocido, isAppEnabled() creaba y guardaba un ConnectedApp con enabled=true. La comprobación concedía el acceso que debía verificar.

Paso 3

El control compartido abre varias funciones

getApi() usaba ese resultado para atender llamadas AIDL. GHSL indica que el camino alcanzaba 97 métodos, entre ellos getAppInfo() y operaciones de copia de archivos.

Paso 4

El impacto conserva los límites documentados

La app maliciosa ya debe estar instalada en el dispositivo. GHSL documenta exposición de ubicación/navegación y efectos en archivos del sandbox de OsmAnd; no demuestra acceso a todo el dispositivo ni explotación real de clientes.

Código Fuente: Vulnerable vs. Seguro

El fragmento vulnerable se cita del análisis de GHSL sobre la versión 5.3.3 probada. El ejemplo inferior es un esquema mínimo de política fail-closed, no el parche de OsmAnd ni una implementación completa: el flujo de aprobación debe verificar UID, firma del paquete instalado, consentimiento del usuario y los permisos necesarios para cada método. Un servicio de producción debe aplicar autorización en el límite Binder y restringir por separado los métodos sensibles. GHSL confirma una corrección, pero no publica el diff completo ni la primera versión corregida; actualiza a una versión compatible y verifica las indicaciones actuales del proveedor. El código es educativo y no incluye exploit ni payload de ubicación/archivo.

Fragmento de origen: Método: isAppEnabled()

IMPLEMENTACIÓN VULNERABLE

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();
}

PARCHE SEGURO Y ROBUSTO

private final Set<Integer> approvedCallerUids = new HashSet<>();

private boolean isAppEnabled() {
    // Complete el campo solo después de la aprobación explícita del usuario y de verificar su identidad.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Lista de Verificación de Seguridad para Ingeniería

✓Actualiza OsmAnd a una versión compatible. GHSL confirma que se corrigió, pero no indica la primera versión corregida; no deduzcas el límite de parche a partir de la fecha del aviso.
✓En servicios Android, deniega por defecto los UID Binder desconocidos. Concede acceso solo tras aprobación explícita del usuario y verificación de la firma del paquete instalado.
✓Aplica autorización en el límite del servicio exportado y limita cada método AIDL; una autorización general no debe exponer automáticamente ubicación, registros ni operaciones de archivos.
✓Trata como no confiables los nombres de paquete recibidos como argumentos. Obtén la identidad mediante Binder.getCallingUid() y valida la relación paquete-UID y el certificado de firma.
✓Limita cada operación de archivos a una raíz canónica propiedad de la app y rechaza rutas que salgan de ella; la autorización no sustituye la validación de rutas.
✓Revisa los manifests Android en busca de servicios exportados sin permisos y prueba primeras llamadas, revocación, reinstalación/cambio de firma y cada método AIDL sensible.
✓El aviso describe un PoC de investigación, no explotación confirmada contra dispositivos de clientes. Investiga señales locales sin tratar la divulgación, por sí sola, como prueba de compromiso.