FlawOpen

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

● CVE-2026-65995 · 高
セキュリティ研究 · FlawOpen

CVE-2026-65995：OsmAnd AIDLの認可バイパス

OsmAnd 5.3.3は、公開されたAndroid AIDLサービスで未知の呼び出し元を自動承認し、端末にインストール済みのアプリから位置情報やファイル操作へアクセスできる状態でした。公開アドバイザリは修正を確認していますが、最初の修正版やCVSSスコアは示していません。

💡 わかりやすい解説 (ELI5)

来訪者名簿を確認するはずのビル受付が、新しい訪問者を到着した瞬間に承認済みリストへ追加する様子を想像してください。OsmAndのサービスは同じ端末のアプリに対して同じことをしていました。未知の呼び出し元を有効として登録し、連携インターフェースを使わせていました。修正では明示的な承認を求め、呼び出し元の正しいAndroid IDに結び付ける必要があります。

主要な概念と専門用語

AIDL
Android Interface Definition Language。Binder IPCを通じて、あるAndroidプロセスから別プロセスが公開するメソッドを呼び出す仕組みです。
公開サービス
他のアプリが接続できるAndroidサービスです。機密メソッドはpermissionまたは同等の呼び出し元検証で保護します。
呼び出し元UID
OSがアプリプロセスに割り当てるIDです。呼び出し元が渡すパッケージ名を信用せず、Binderから取得します。
CWE-862
共有された認可境界の欠落に対するFlawOpenの編集上の分類です。GHSLは複数の弱点の一つとしてCWE-862を記載していますが、CVSSスコアは公表していません。

フレームワーク対応

  • FlawOpenによるMITRE CWEへの概念上の対応付けです。ベンダーやCVEレコードがこの研究デモに弱点IDを割り当てたものではありません。 CWE-862

根本原因の分析 (Root Cause)

GitHub Security LabはOsmAnd 5.3.3を調査し、公開されたOsmandAidlServiceV2にAndroid permissionがなく、OsmandAidlApi.isAppEnabled()が未知のConnectedAppをenabled=trueで作成すると報告しました。getApi()はこの判定でAIDL呼び出しを制御していたため、新規のローカルアプリをユーザー承認まで拒否せず、認可済みとして保存していました。GHSLによると、これにより位置情報やナビゲーション情報を返すメソッド、パストラバーサルのあるファイル操作など97のAIDLメソッドが露出しました。攻撃者は同じ端末にアプリを事前インストールする必要がありますが、位置情報permissionや追加のユーザー操作は不要です。ファイルへの影響はOsmAndのストレージサンドボックス内であり、端末全体のファイルシステムへのアクセスではありません。開発者は2026年6月28日に修正を確認しましたが、アドバイザリは最初の修正版を示していません。CVSSスコアは公表されていません。FlawOpenは位置情報の漏えいと完全性に影響する操作が露出したため、重大度を編集判断でHighとしています。CWE-862はFlawOpenの主要な編集上の対応付けであり、GHSLがそれだけを割り当てたという意味ではありません。

ステップ・バイ・ステップの攻撃フロー

ステップ 1

ローカルアプリが公開サービスへ接続

脆弱なサービスはAndroid permissionなしで公開されていました。同じ端末のアプリはOsmAndの位置情報permissionを求めずに接続できました。

ステップ 2

認可確認が自ら承認を作成

未知のパッケージに対してisAppEnabled()はenabled=trueのConnectedAppを作成して保存しました。確認処理が本来検証すべきアクセスを付与していました。

ステップ 3

共有ゲートから複数機能へ到達

getApi()はその結果を使ってAIDL呼び出しを処理しました。GHSLによると、getAppInfo()やファイルコピーを含む97メソッドに到達できました。

ステップ 4

影響範囲は確認済みの条件に限定

悪意あるアプリは端末にインストール済みである必要があります。GHSLが示すのは位置/ナビゲーション情報の露出とOsmAndサンドボックス内のファイル影響であり、端末全体へのアクセスや顧客環境での実悪用ではありません。

ソースコード比較：脆弱 vs 堅牢化

脆弱な抜粋はGHSLが調査した5.3.3の分析から引用しています。下の例は最小限のfail-closed方針のスケッチで、OsmAndのパッチでも完全な認可実装でもありません。承認フローではUID、インストール済みパッケージの署名、ユーザー同意、各メソッドに必要な権限範囲を検証する必要があります。本番サービスではBinder境界で認可し、機密メソッドごとにも権限を制限してください。GHSLは修正を確認していますが、完全なdiffや最初の修正版は公開していません。サポート対象版へ更新し、ベンダーの最新情報を確認してください。コードは教育用で、exploitや位置/ファイルpayloadを含みません。

ソース抜粋: メソッド：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());
}

エンジニアリング＆システム堅牢化チェックリスト

参考資料