CVE-2026-65995: Bypass otorisasi AIDL OsmAnd

OsmAnd 5.3.3 otomatis menyetujui pemanggil tak dikenal melalui layanan Android AIDL yang diekspor, sehingga aplikasi yang sudah terpasang di perangkat dapat mengakses data lokasi dan operasi berkas. Advisory mengonfirmasi perbaikan, tetapi tidak menyebut rilis pertama yang aman atau skor CVSS.

💡 Penjelasan Sederhana (ELI5)

Bayangkan resepsionis gedung yang seharusnya memeriksa daftar tamu, tetapi langsung menambahkan setiap pengunjung baru ke daftar yang disetujui. Layanan OsmAnd melakukan hal serupa terhadap aplikasi di ponsel yang sama: pemanggil tak dikenal dicatat sebagai aktif lalu diberi akses ke antarmuka integrasi. Perbaikan harus meminta persetujuan eksplisit dan mengikatnya ke identitas Android pemanggil yang sebenarnya.

Konsep Kunci & Istilah

AIDL: Android Interface Definition Language: mekanisme agar proses Android memanggil metode yang dibuka proses lain melalui Binder IPC.
Layanan yang diekspor: Layanan Android yang dapat dihubungi aplikasi lain. Metode sensitif harus dilindungi permission atau pemeriksaan pemanggil yang setara.
UID pemanggil: Identitas proses aplikasi yang ditetapkan sistem operasi. Layanan harus mengambilnya dari Binder, bukan memercayai nama paket yang dikirim pemanggil.
CWE-862: Klasifikasi editorial FlawOpen untuk batas otorisasi bersama yang hilang. GHSL mencantumkan CWE-862 di antara beberapa kelemahan; advisory tidak menerbitkan skor CVSS.

Pemetaan kerangka kerja

Pemetaan konseptual FlawOpen ke MITRE CWE; tidak ada vendor atau catatan CVE yang menetapkan ID kelemahan ini untuk demonstrasi riset tersebut. CWE-862

Analisis Akar Masalah (Root Cause)

GitHub Security Lab menguji OsmAnd 5.3.3 dan menemukan OsmandAidlServiceV2 yang diekspor tanpa permission Android serta OsmandAidlApi.isAppEnabled() yang membuat ConnectedApp tak dikenal dengan enabled=true. Karena getApi() memakai pemeriksaan ini untuk mengizinkan panggilan AIDL, aplikasi lokal baru disimpan sebagai terotorisasi alih-alih ditolak sampai pengguna menyetujuinya. GHSL menyatakan 97 metode AIDL terbuka, termasuk metode yang mengembalikan data lokasi/navigasi dan operasi berkas dengan kelemahan path traversal. Penyerang harus sudah memasang aplikasi pada perangkat yang sama, tetapi aplikasi itu tidak memerlukan permission lokasi atau tindakan tambahan dari pengguna. Dampak berkas yang dijelaskan GHSL terbatas pada sandbox penyimpanan OsmAnd, bukan seluruh sistem berkas perangkat. Maintainer mengonfirmasi perbaikan pada 28 Juni 2026, tetapi advisory tidak menyebut rilis pertama yang diperbaiki. Skor CVSS tidak diterbitkan; FlawOpen memberi tingkat keparahan editorial High karena data lokasi dan operasi yang memengaruhi integritas terekspos. CWE-862 adalah pemetaan editorial utama FlawOpen, bukan satu-satunya klasifikasi yang diberikan GHSL.

Alur Serangan Langkah demi Langkah

Langkah 1

Aplikasi lokal mencapai layanan yang diekspor

Layanan rentan diekspor tanpa permission Android. Aplikasi yang sudah terpasang di perangkat yang sama dapat terhubung tanpa meminta permission lokasi OsmAnd.

Langkah 2

Pemeriksaan membuat persetujuannya sendiri

Untuk paket tak dikenal, isAppEnabled() membuat dan menyimpan ConnectedApp dengan enabled=true. Pemeriksaan justru memberikan akses yang seharusnya diverifikasi.

Langkah 3

Gerbang bersama membuka banyak kemampuan

getApi() menggunakan hasil tersebut untuk melayani panggilan AIDL. GHSL menyebut jalur ini menjangkau 97 metode, termasuk getAppInfo() dan operasi salin berkas.

Langkah 4

Dampak mengikuti batas yang terdokumentasi

Aplikasi berbahaya harus sudah terpasang pada perangkat. GHSL menjelaskan kebocoran lokasi/navigasi dan dampak berkas di sandbox OsmAnd; akses ke seluruh perangkat atau eksploitasi nyata pada pelanggan tidak dibuktikan.

Kode Sumber: Rentan vs Aman

Kutipan rentan berasal dari analisis GHSL atas versi 5.3.3 yang diuji. Contoh di bawah adalah sketsa kebijakan fail-closed minimal, bukan patch OsmAnd atau implementasi otorisasi lengkap: alur persetujuan harus memverifikasi UID, tanda tangan paket terpasang, persetujuan pengguna, dan cakupan setiap metode. Layanan produksi harus menegakkan otorisasi di batas Binder dan membatasi metode sensitif secara terpisah. GHSL mengonfirmasi perbaikan tetapi tidak menerbitkan diff lengkap atau rilis pertama yang diperbaiki; perbarui ke rilis yang didukung dan verifikasi panduan vendor terbaru. Kode ini untuk edukasi dan tidak menyertakan exploit atau payload lokasi/berkas.

Cuplikan sumber: Metode: isAppEnabled()

IMPLEMENTASI RENTAN

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

PERBAIKAN AMAN & KUAT

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

private boolean isAppEnabled() {
    // Isi hanya setelah pengguna memberikan persetujuan eksplisit dan identitasnya terverifikasi.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Daftar Periksa Penguatan Sistem Rekayasa

✓Perbarui OsmAnd ke rilis yang masih didukung. GHSL mengonfirmasi perbaikan tetapi tidak menyebut rilis pertama yang aman; jangan menyimpulkan batas versi hanya dari tanggal advisory.
✓Pada layanan Android, tolak UID Binder yang tidak dikenal secara default. Berikan akses hanya setelah persetujuan eksplisit pengguna dan verifikasi tanda tangan paket terpasang.
✓Terapkan otorisasi pada batas layanan yang diekspor dan batasi setiap metode AIDL; persetujuan umum tidak boleh otomatis membuka lokasi, log, atau operasi berkas.
✓Anggap nama paket dalam argumen sebagai input tidak tepercaya. Ambil identitas dengan Binder.getCallingUid() dan verifikasi hubungan paket-UID serta sertifikat penandatangan.
✓Batasi operasi berkas ke root kanonis milik aplikasi dan tolak jalur yang keluar darinya; otorisasi tidak menggantikan validasi jalur.
✓Periksa manifest Android untuk layanan diekspor tanpa permission, lalu uji pemanggil pertama kali, pencabutan persetujuan, instal ulang/perubahan tanda tangan, dan setiap metode AIDL sensitif.
✓Advisory melaporkan PoC peneliti, bukan eksploitasi terkonfirmasi terhadap perangkat pelanggan. Selidiki indikator lokal tanpa menganggap pengungkapan saja sebagai bukti kompromi.