CVE-2026-65995 : contournement d’autorisation AIDL dans OsmAnd

OsmAnd 5.3.3 approuvait automatiquement des appelants inconnus via un service Android AIDL exporté, exposant localisation et opérations sur les fichiers à toute application déjà installée. L’avis confirme un correctif, sans préciser la première version corrigée ni publier de score CVSS.

💡 Explication en Langage Simple (ELI5)

Imaginez l’accueil d’un immeuble qui devrait consulter une liste d’invités, mais ajoute chaque nouveau visiteur à la liste des personnes autorisées dès son arrivée. Le service d’OsmAnd faisait l’équivalent pour les applications du même téléphone : il enregistrait les appelants inconnus comme autorisés, puis leur ouvrait l’interface d’intégration. La correction doit exiger un accord explicite et le lier à l’identité Android réelle de l’appelant.

Concepts Clés et Termes

AIDL: Android Interface Definition Language : mécanisme permettant à un processus Android d’appeler les méthodes exposées par un autre via Binder IPC.
Service exporté: Service Android auquel d’autres applications peuvent se connecter. Les méthodes sensibles doivent être protégées par une permission ou un contrôle équivalent de l’appelant.
UID de l’appelant: Identité du processus attribuée par le système. Le service doit la lire depuis Binder, sans faire confiance au nom de paquet fourni par l’appelant.
CWE-862: Classification éditoriale de FlawOpen pour l’absence du contrôle d’autorisation commun. GHSL cite CWE-862 parmi plusieurs faiblesses ; l’avis ne publie pas de score CVSS.

Correspondances de référentiels

Correspondance conceptuelle de FlawOpen avec MITRE CWE ; aucun fournisseur ni enregistrement CVE n’a attribué cet identifiant de faiblesse à cette démonstration de recherche. CWE-862

Analyse de Cause Racine

GitHub Security Lab a testé OsmAnd 5.3.3 et constaté que OsmandAidlServiceV2 était exporté sans permission Android et que OsmandAidlApi.isAppEnabled() créait un ConnectedApp inconnu avec enabled=true. Comme getApi() conditionnait les appels AIDL à ce contrôle, une nouvelle application locale était enregistrée comme autorisée au lieu d’être refusée jusqu’à l’accord de l’utilisateur. Selon GHSL, cela exposait 97 méthodes AIDL, dont des méthodes renvoyant des données de localisation/navigation et des opérations de fichiers comportant des failles de traversée de chemin. L’attaquant doit déjà avoir une application installée sur le même appareil, mais celle-ci n’a besoin ni de permission de localisation ni d’une autre action de l’utilisateur. Les effets sur les fichiers décrits par GHSL restent dans le stockage isolé d’OsmAnd, pas dans tout le système de fichiers. Les mainteneurs ont confirmé les correctifs le 28 juin 2026, sans indiquer la première version corrigée. Aucun score CVSS n’est publié ; FlawOpen attribue éditorialement une sévérité élevée en raison de l’exposition de données de localisation et d’opérations affectant l’intégrité. CWE-862 est le mappage éditorial principal de FlawOpen, et non une classification unique attribuée par GHSL.

Déroulement de l'Attaque Étape par Étape

Étape 1

Une application locale atteint le service exporté

Le service vulnérable était exporté sans permission Android. Une application installée sur le même appareil pouvait s’y connecter sans demander la permission de localisation d’OsmAnd.

Étape 2

Le contrôle crée lui-même l’autorisation

Pour un paquet inconnu, isAppEnabled() créait puis enregistrait un ConnectedApp avec enabled=true. Le contrôle accordait l’accès qu’il devait vérifier.

Étape 3

La barrière commune ouvre plusieurs fonctions

getApi() utilisait ce résultat pour répondre aux appels AIDL. GHSL indique que le chemin atteignait 97 méthodes, dont getAppInfo() et des opérations de copie de fichiers.

Étape 4

L’impact reste dans les limites documentées

L’application malveillante doit déjà être installée sur l’appareil. GHSL décrit une divulgation de localisation/navigation et des effets dans le stockage isolé d’OsmAnd ; aucun accès à tout l’appareil ni exploitation réelle de clients n’est établi.

Code Source : Vulnérable vs Sécurisé

L’extrait vulnérable est cité de l’analyse GHSL de la version 5.3.3 testée. L’exemple inférieur est un schéma minimal de politique fail-closed, pas le correctif d’OsmAnd ni une implémentation complète : le processus d’approbation doit vérifier l’UID, la signature du paquet installé, le consentement de l’utilisateur et les portées nécessaires à chaque méthode. Un service de production doit appliquer l’autorisation à la frontière Binder et restreindre séparément les méthodes sensibles. GHSL confirme un correctif, mais ne publie ni le diff complet ni la première version corrigée ; installez une version prise en charge et vérifiez les consignes actuelles du fournisseur. Le code est pédagogique et ne contient aucun exploit ni charge utile de localisation/fichier.

Extrait source: Méthode : isAppEnabled()

IMPLÉMENTATION VULNÉRABLE

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

PATCH SÉCURISÉ ET ROBUSTE

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

private boolean isAppEnabled() {
    // Renseignez ce champ uniquement après l’approbation explicite de l’utilisateur et la vérification de son identité.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Mettez OsmAnd à jour vers une version prise en charge. GHSL confirme le correctif sans préciser la première version corrigée ; ne déduisez pas de seuil à partir de la date de l’avis.
✓Dans les services Android, refusez par défaut les UID Binder inconnus. N’accordez l’accès qu’après consentement explicite et vérification de la signature du paquet installé.
✓Appliquez l’autorisation à la frontière du service exporté et limitez chaque méthode AIDL ; une autorisation générale ne doit pas exposer automatiquement localisation, journaux ou opérations de fichiers.
✓Traitez les noms de paquet reçus en argument comme non fiables. Obtenez l’identité via Binder.getCallingUid() et vérifiez les liens paquet-UID et certificat de signature.
✓Limitez chaque opération de fichier à une racine canonique appartenant à l’application et rejetez les chemins qui en sortent ; l’autorisation ne remplace pas la validation des chemins.
✓Examinez les manifests Android pour repérer les services exportés sans permission, puis testez les premiers appels, révocations, réinstallations/changements de signature et chaque méthode AIDL sensible.
✓L’avis rapporte une preuve de concept de recherche, pas une exploitation confirmée d’appareils clients. Enquêtez sur les signes locaux sans considérer la divulgation seule comme une preuve de compromission.