CVE-2026-65995: OsmAnd-AIDL-Autorisierungsumgehung

OsmAnd 5.3.3 schaltete unbekannte Aufrufer über einen exportierten Android-AIDL-Dienst automatisch frei. Dadurch waren Standort- und Dateioperationen für jede bereits installierte App erreichbar. Der Advisory bestätigt eine Behebung, nennt aber weder die erste korrigierte Version noch einen CVSS-Wert.

💡 Einfache Erklärung (ELI5)

Stellen Sie sich einen Empfang vor, der eigentlich eine Gästeliste prüfen soll, aber jeden neuen Besucher sofort auf die Freigabeliste setzt. OsmAnds Dienst tat etwas Ähnliches mit Apps auf demselben Telefon: Er speicherte unbekannte Aufrufer als aktiviert und öffnete ihnen dann die Integrationsschnittstelle. Die Behebung muss eine ausdrückliche Freigabe verlangen und sie an die echte Android-Identität des Aufrufers binden.

Kernkonzepte & Begriffe

AIDL: Android Interface Definition Language: ein Mechanismus, mit dem ein Android-Prozess Methoden eines anderen Prozesses über Binder IPC aufrufen kann.
Exportierter Dienst: Ein Android-Dienst, an den sich andere Apps binden können. Sensible Methoden benötigen eine Berechtigung oder eine gleichwertige Prüfung des Aufrufers.
Aufrufer-UID: Die vom Betriebssystem vergebene Identität des App-Prozesses. Der Dienst muss sie über Binder beziehen und darf keinem vom Aufrufer gelieferten Paketnamen vertrauen.
CWE-862: FlawOpens redaktionelle Einordnung der fehlenden gemeinsamen Autorisierungsschranke. GHSL nennt CWE-862 neben weiteren Schwächen; der Advisory veröffentlicht keinen CVSS-Wert.

Framework-Zuordnungen

Konzeptionelle Zuordnung von FlawOpen zu MITRE CWE; weder ein Anbieter noch ein CVE-Datensatz hat diese Schwachstellen-ID dieser Forschungsdemonstration zugewiesen. CWE-862

Ursachenanalyse

GitHub Security Lab testete OsmAnd 5.3.3 und stellte fest, dass OsmandAidlServiceV2 ohne Android-Berechtigung exportiert war und OsmandAidlApi.isAppEnabled() einen unbekannten ConnectedApp mit enabled=true anlegte. Da getApi() AIDL-Aufrufe von dieser Prüfung abhängig machte, wurde eine neue lokale App als autorisiert gespeichert, statt bis zur Zustimmung des Nutzers abgewiesen zu werden. Laut GHSL öffnete dies 97 AIDL-Methoden, darunter Methoden für Standort-/Navigationsdaten und Dateioperationen mit Path-Traversal-Schwächen. Der Angreifer benötigt bereits eine installierte App auf demselben Gerät; diese braucht jedoch weder OsmAnds Standortberechtigung noch eine weitere Nutzeraktion. Die beschriebenen Dateiauswirkungen bleiben im OsmAnd-Speichersandbox, nicht im gesamten Geräte-Dateisystem. Die Maintainer bestätigten die Behebungen am 28.06.2026, nannten aber nicht die erste korrigierte Version. Ein CVSS-Wert wurde nicht veröffentlicht; FlawOpen stuft die Auswirkung redaktionell als Hoch ein, da Standortdaten und integritätsrelevante Dateioperationen offenlagen. CWE-862 ist FlawOpens primäre redaktionelle Zuordnung, keine alleinige GHSL-Klassifikation.

Schritt-für-Schritt Angriffsablauf

Schritt 1

Eine lokale App erreicht den exportierten Dienst

Der verwundbare Dienst war ohne Android-Berechtigung exportiert. Eine App auf demselben Gerät konnte sich verbinden, ohne OsmAnds Standortberechtigung anzufordern.

Schritt 2

Die Prüfung legt selbst eine Freigabe an

Für ein unbekanntes Paket legte isAppEnabled() einen ConnectedApp mit enabled=true an und speicherte ihn. Die Prüfung gewährte damit den Zugriff, den sie prüfen sollte.

Schritt 3

Die gemeinsame Schranke öffnet mehrere Funktionen

getApi() nutzte dieses Ergebnis für AIDL-Aufrufe. GHSL zufolge waren 97 Methoden erreichbar, darunter getAppInfo() und Datei-Kopieroperationen.

Schritt 4

Die Auswirkungen bleiben innerhalb der belegten Grenzen

Die schädliche App muss bereits auf dem Gerät installiert sein. GHSL beschreibt Standort-/Navigationsdaten und Dateiänderungen im OsmAnd-Speichersandbox; Zugriff auf das ganze Gerät oder reale Kundenausnutzung ist nicht belegt.

Quellcode: Verwundbar vs. Sicher

Der verwundbare Ausschnitt stammt aus GHSLs Analyse der getesteten Version 5.3.3. Das untere Beispiel ist eine minimale fail-closed-Policy-Skizze, nicht OsmAnds Patch oder eine vollständige Implementierung: Der Freigabeprozess muss UID, Signatur des installierten Pakets, Nutzereinwilligung und die benötigten Berechtigungsbereiche je Methode prüfen. Ein produktiver Dienst sollte die Autorisierung an der Binder-Grenze und zusätzlich pro sensibler Methode durchsetzen. GHSL bestätigt eine Behebung, veröffentlicht aber weder den vollständigen Diff noch die erste korrigierte Version; installieren Sie eine unterstützte Version und prüfen Sie die aktuellen Herstellerhinweise. Der Code ist lehrreich und enthält keinen Exploit oder Standort-/Datei-Payload.

Quelltextauszug: Methode: isAppEnabled()

VERWUNDBARE IMPLEMENTIERUNG

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

GEHÄRTETER SICHERHEITS-PATCH

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

private boolean isAppEnabled() {
    // Befüllen Sie das Feld erst nach ausdrücklicher Zustimmung des Nutzers und verifizierter Identität.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Checkliste für Engineering & Systemsicherheit

✓Aktualisieren Sie OsmAnd auf eine aktuell unterstützte Version. GHSL bestätigt die Behebung, nennt aber nicht die erste korrigierte Version; leiten Sie keinen Patch-Stand allein aus dem Advisory-Datum ab.
✓Lehnen Sie bei Android-Diensten unbekannte Binder-UIDs standardmäßig ab. Gewähren Sie Zugriff erst nach ausdrücklicher Nutzerfreigabe und Prüfung der Signatur des installierten Pakets.
✓Setzen Sie Autorisierung an der Grenze des exportierten Dienstes durch und beschränken Sie jede AIDL-Methode einzeln; eine allgemeine Freigabe darf Standort, Logs oder Dateioperationen nicht automatisch öffnen.
✓Behandeln Sie als Argument übergebene Paketnamen als nicht vertrauenswürdig. Ermitteln Sie die Identität über Binder.getCallingUid() und prüfen Sie Paket-UID- und Signaturbindungen.
✓Beschränken Sie Dateioperationen auf ein kanonisches, der App gehörendes Stammverzeichnis und weisen Sie ausbrechende Pfade zurück; Autorisierung ersetzt keine Pfadvalidierung.
✓Prüfen Sie Android-Manifeste auf exportierte Dienste ohne Berechtigung und testen Sie Erstaufrufe, widerrufene Freigaben, Neuinstallation/Signaturwechsel und jede sensible AIDL-Methode.
✓Der Advisory berichtet einen Forschungs-PoC, keine bestätigte Ausnutzung von Kundengeräten. Untersuchen Sie lokale Hinweise, ohne die Veröffentlichung allein als Kompromittierungsbeleg zu behandeln.