macOSの権限ポップアップ、信頼してよいのか？

• CVE-2025-31250は、macOSのTCC権限同意ポップアップを信頼しにくくする脆弱性で、画面に表示されるアプリと実際に権限を受け取るアプリを別々にできていた
• 問題はtccdのTCCAccessRequestIndirect処理にあり、target_pathはポップアップに表示されるアプリ名に、target_identifierは実際に権限を受け取るアプリ識別子に使われていた
• 従来の回避手法のような偽アプリ・Dockショートカット・ユーザーのクリック誘導は不要で、ユーザーがスプーフィングされたポップアップでAllowを押すと攻撃が成立し得た
• AppleはmacOS Sequoia 15.5で修正したが、同日に公開されたVentura 13.7.6とSonoma 14.7.6には修正を適用しておらず、以前のバージョンへの修正計画もないことを確認した
• 攻撃者はFaceTime、Voice Memos、System Settingsのようなアプリが開く瞬間を狙って権限ポップアップのスプーフィングを試みることができ、ユーザーが実際の権限付与先を誤認する危険がある

---

CVE-2025-31250の中核的な挙動

• CVE-2025-31250は、macOSのTCC権限ポップアップで表示されるアプリと、実際に権限を受け取るアプリを別々にできていた脆弱性
• 修正前には次のような構成が可能だった
  • Application AがmacOSに権限同意ポップアップの表示を要求する
  • ポップアップはApplication Bからのもののように見える
  • ユーザーの同意結果はApplication Cに適用される
• 3つのアプリは互いに異なっていてもよく、通常の利用では同じアプリである可能性が高い
• 中核的な問題は、ポップアップに表示されるアプリと実際の権限受領アプリが異なっていても、十分な検証が行われていなかった点にある

修正適用範囲と訂正事項

• 当初の説明とは異なり、修正はmacOS Sequoia 15.5にのみ適用されている
• 同日にリリースされたmacOS Ventura 13.7.6とmacOS Sonoma 14.7.6には修正が含まれていない
• Sonoma 14.7.6の仮想マシンでPoCをコンパイルして実行したところ、脆弱性は依然として再現した
• Apple Product Securityは報告ステータスを“We’ve addressed the issue in all planned releases.”に変更し、その後VenturaとSonomaにはこの脆弱性の修正計画がないことを確認した
• 結果として、VenturaとSonomaはこの脆弱性に対して脆弱な状態のまま残っている

TCCとApple Eventsが交わる地点

• TCCはAppleオペレーティングシステムの中核的な権限システムであり、内部的にはtccdデーモンとprivate TCCフレームワークを通じて動作する
• 開発者がprivate APIを直接呼び出すことはないが、public APIが必要になる場面で内部的にTCC機能が呼び出される
• tccdはAppleのXPC APIを使ってメッセージを受け取る
• 修正前は、XPCメッセージをtccdに送れるアプリが細工されたメッセージを送り、権限ポップアップ表示アプリと実際の権限受領アプリを分離できていた

Apple EventsとTCCデータモデル

• Apple EventsはmacOSにおけるプロセス間通信方式で、現在は主に自動化用途で使われている
• Apple Events自動化はAppleのOpen Scripting Architectureを通じてスクリプト化できる
  • 代表的な言語はAppleScript
  • JavaScriptも利用できる
• macOS Mojave 10.14以降、アプリがApple Eventsを送信するにはTCCを通じたユーザー同意が必要になった
• TCCにおけるユーザー同意結果は、ユーザーのホームフォルダ配下のApplication Support/com.apple.TCC/TCC.db SQLiteデータベースに保存される
• 一般的なTCC行には、要求アプリ、要求サービス、ユーザー同意結果が含まれる
• Apple Eventsは受信アプリごとに権限を制限する必要があるため、indirect objectカラムを使用する
  • このカラムにはApple Eventsを受け取るアプリの識別子が入る
  • Apple Events以外ではFileProviderDomainサービスもこのカラムを使用する

脆弱なXPCメッセージ構造

• 問題はTCCAccessRequestIndirect関数のロジックバグにあった
• この関数はTCC.dbのindirect objectカラムを使うべきアクセス要求を処理する
• PoCの核心は、target_promptが2のときに2つのフィールドを分離して入れる方式にある
  • target_path: GUI権限ポップアップに表示するアプリ名を取得するために使われる
  • target_identifier: 実際にデータベースへ記録されて権限を受け取るアプリのバンドルIDとして使われる
• TCCAccessRequestIndirectはindirect object用の関数であるにもかかわらず、空文字列をindirect objectとして入れることで、そのカラムを使わない複数のTCCサービスにも利用できていた
• このバグは他のアクセス要求関数には存在しなかった

悪用条件と制約

• 脆弱性の悪用は、ユーザーが権限ポップアップでAllowを押した場合に成功する
• 利用可能なTCCサービスは限られていたが、MicrophoneやCameraのような主要サービスが含まれていた
• 特定ディレクトリへのアクセス権ポップアップもスプーフィングできたが、ファイル周辺の追加セキュリティ層のため有用性は低かった
• 悪意あるアプリが権限を自分自身ではなく別のアプリに適用させることも可能だった
  • 攻撃者が別アプリを制御できるが、そのアプリにTCC権限が必要な場合に活用できる経路である

ポップアップのタイミングを利用しただまし

• ランダムに権限ポップアップが出ると、ユーザーは不審に思ってDon’t Allowを押す可能性がある
• macOSアプリは実行中のアプリケーション一覧と現在の最前面アプリを確認できる
  • 実行中アプリの確認: NSWorkspace runningApplications
  • 最前面アプリの確認: NSWorkspace frontmostApplication
• 悪意あるアプリは特定アプリが起動したり最前面になったりする時点まで待ち、そのアプリ名でスプーフィングされた権限ポップアップを表示できる
• たとえばFaceTime起動時にCamera権限ポップアップを、Voice Memos起動時にMicrophone権限ポップアップをスプーフィングできる
• ユーザーは、アプリを開いたり切り替えたりした直後に現れたポップアップを、そのアプリによる正規の権限要求だと誤認する可能性がある

既存のTCC回避経路とのつながり

• 以前はtccdがユーザーのホームフォルダをHOME環境変数で判断していたため、偽のホームフォルダと偽のTCC.dbを仕込むことでTCC回避が可能だった
• この問題は2020年7月中旬のアップデートで修正され、その後tccdはOSのユーザー情報ディレクトリからホームフォルダを参照するようになった
• その後もユーザーのホームフォルダ変更を悪用した回避事例があった
  • Wojciech Regułaは、macOSのGUIユーザー情報ディレクトリエディタのプラグインシステムを悪用したCVE-2020-27937を公開した
  • Microsoft Threat Intelligenceチームはimport/exportコマンドを利用したpowerdir回避を公開した
• ユーザーのホームフォルダを変更するには、通常2つが必要になる
  • root権限
  • 特定のTCCサービスに対するユーザー同意
• CVE-2025-31250はroot権限要件を回避することはできないが、必要なTCC同意をスプーフィングされたポップアップで誘導できる
• 悪意あるアプリがユーザーをだまして同意を得て、さらにroot権限昇格まで確保すれば、ユーザー情報ディレクトリを変更して偽のTCC.dbを仕込む経路が可能になる
• REG.dbは有効なTCC.dbを追跡しているが、TCCにはアプリがREG.dbに項目を追加できる関数があり、仕込んだTCC.dbのパスを追加できる

ユーザーから見える権限管理の限界

• TCCはSystem SettingsのPrivacy & Securityパネルの背後で動作するシステムである
• Apple Events関連の同意結果はAutomationセクションに表示される
• Privacy & Securityパネルでは、ユーザーが付与した同意を確認でき、多くの場合は特定の同意を取り消せる
• しかし、攻撃者がユーザーをだましてApple Events権限を許可させた場合、その同意結果はSystem Settingsに表示されなかった
• ユーザーはtccutil CLIツールで同意を取り消せるが、このツールは文書化が限定的で、ほとんどのユーザーには知られていない
  • Appleの文書としては古いTechnical Q&AとIT training pageがある

Endpoint Securityと検知可能性

• AppleのEndpoint Securityフレームワークは、最近TCCデータベース変更の監視をサポートし始めた
• Objective-Seeの記事はこの変更を扱っている: Endpoint Security TCC database monitoring
• この機能が期待どおりに動作するなら、フレームワークを使うアプリは、実際にどのアプリへ権限が付与されたかをユーザーに事後通知できる
• ただし、この検知可能性が直接的な意味を持ったのは、AppleがEndpoint Securityイベントを追加した時点と脆弱性修正の間にある短い期間だけだった

Appleの修正方法

• macOS Sequoia 15.5のtccdバイナリ解析の結果、最終的な修正は当初の推測よりも複雑だった
• 修正後は同じ方法でTCCポップアップをスプーフィングできない
• indirect objectに空文字列を入れて他のTCCサービスにTCCAccessRequestIndirectを使う挙動も制限されたように見える
• 脆弱な形式のメッセージは、現在ではtccdで静かに破棄され、何も動作しないことが観測されている
• 簡易な検証では良い修正に見えたが、全体の動作を完全に理解するには追加分析が必要である

報告から修正までの流れ

• この脆弱性はAppleに報告された2件目のバグであり、Appleが修正した報告案件の中で修正まで最も長くかかった事例だった
• 報告過程には、初期報告、Apple Product Securityからの追加説明要求、潜在的な完全TCC回避経路の共有、PoCテスト更新、再現状況の確認、複数回の進捗問い合わせが含まれていた
• 提案された単純な修正は、2つのフィールドが同じアプリを指しているかを検証する方式だった
• Appleは調査中であるという回答を複数回返し、その後クレジット表記名を求めたうえで修正をリリースした
• 脆弱性名は「TCC, Who?」と付けられた