- macOSのTCC権限システムに欠陥があり、ユーザーに誤認を招く権限要求ポップアップを表示できていた
- この脆弱性はCVE-2025-31250として登録されており、ユーザーの同意が別のアプリに適用される問題である
- 悪意あるアプリが権限要求ウィンドウを信頼されたアプリ名で表示し、ユーザーの同意を誘導するスプーフィング攻撃の可能性がある
- AppleのmacOS Sequoia 15.5で修正されたが、ほかのバージョンでは依然として未修正の状態である
- 権限付与履歴の確認および取り消しの難しさに加え、今後も類似の脆弱性が発生する可能性がある
重要な訂正
- この脆弱性はmacOS Sequoia 15.5で修正されたが、macOS Ventura 13.7.6およびmacOS Sonoma 14.7.6ではまだ修正されていない
- Appleのセキュリティリリースノートに報告者への言及がないことを確認した
- 仮想マシン上でmacOS Sonoma 14.7.6を直接テストし、脆弱性が依然として悪用可能であることを検証した
- Ventura 13.7.6も同様の状態であると推定される
- Appleからの公式回答を待っている
紹介
- CVE-2025-31250脆弱性は、アプリケーションがmacOSに偽の権限要求ポップアップを表示できるようにする問題である
- "Application A"がポップアップを表示すると、ポップアップには"Application B"と表示され、結果としてユーザーの権限同意は"Application C"に適用される
- 通常は3つのアプリケーションは同一だが、この欠陥により異なるアプリを指定できていた
- これにより権限要求ウィンドウの信頼性に大きな問題が生じる
- 以前にも同様の「スプーフィング」手法がHackTricksなどで紹介されていたが、本脆弱性はより単純な方式である
TCC
- TCCはApple OSに組み込まれた中核的な権限管理システムである
- "tccd"デーモンにメッセージを送ることで権限が管理され、パブリックAPIがプライベートTCCフレームワーク関数を呼び出す
- デーモンはAppleのXPC APIを使ってメッセージ通信を行う
- 本脆弱性が修正される前は、任意のメッセージを送ると権限要求ポップアップを表示するアプリと、実際に権限を付与されるアプリを別々に指定できた
- このような欠陥がなぜ生じたのかを理解するには、Apple Eventsについて知る必要がある
Apple Events
Apple Eventsとは何か
- Apple EventsはmacOSアプリ間のプロセス間通信方式である
- 1993年に出版された古典的な書籍の時代から続くプロトコルである
- macOS X導入後も、構造に合わせて再設計され使われている
- 現代では主に**自動化（Automation）**目的で使われ、AppleScriptおよびJavaScriptでスクリプト化される
- WindowsのScript Hostに似ており、マルウェアのベクターとして悪用されたこともある
Apple EventsとTCC
- macOS Mojave 10.14以降では、Apple Events送信にユーザー同意が必須である
- TCCの権限保存データベース（TCC.db）には、要求アプリ、サービス、そして同意応答情報が記録される
- Apple Eventsは受信アプリごとに権限を分けて管理する必要があるため、TCC.dbのindirect objectカラムが使われる
- TCCデーモンのTCCAccessRequestIndirect関数が、このカラムを利用したメッセージを処理する
- この関数に論理バグが存在し、ユーザーに表示されるアプリと実際に権限を受けるアプリを別々に指定できていた
概念実証（Proof-of-Concept）
- Swiftコード例は次のように権限要求メッセージを操作する
- "spoofedBundle"パスのアプリ名をユーザー同意ポップアップに露出させる
- "actualBundle"のバンドルIDを実際の権限付与対象として指定する
- 結果としてユーザーには信頼できるアプリが権限を要求しているように見えるが、実際の権限は悪意あるアプリに渡る
- "indirect_object"値を空にしても複数のTCCサービスを狙うことができた
- これによりユーザー権限同意の信頼性崩壊が発生する
- 攻撃者はユーザーをだまして任意のアプリが権限を獲得するよう誘導できる
脆弱性の悪用
制限事項と特記事項
- 特定のTCCサービスのみが攻撃に脆弱だが、Microphone、Cameraなど主要サービスは攻撃対象である
- ファイル／フォルダ権限のような場合は追加の保護機構により大きな効果はない
- 悪意あるアプリは、実際に権限を必要とする別アプリの代わりにユーザーが同意するよう、ソーシャルエンジニアリング手法と組み合わせて使うことができる
タイミングの重要性
- ポップアップを表示するタイミングが重要である
- 悪意あるアプリは実行中のアプリと現在前面にあるアプリを検知し、適切なタイミングでポップアップを表示してユーザーを混乱させられる
- 例としてFaceTime起動時にCamera権限ポップアップを表示すれば、ユーザーは正当な権限要求と誤認する可能性がある
- Voice Memos起動時にMicrophone権限要求をスプーフィングするシナリオも可能である
- 文脈に合ったタイミングを狙って悪用すれば成功率が高まる
過去の脆弱性の再検証
- TCC.dbのパスがユーザーのホームフォルダに応じて決まることを悪用した脆弱性が存在した
- 2020年までは
HOME環境変数を変えるだけで偽のTCC.dbを使えた（$HOMERun）
- 修正後もroot権限とユーザー同意は必要だが、ソーシャルエンジニアリングによるスプーフィングと組み合わせれば権限回避が可能である
- 悪意あるアプリは、ユーザーから同意を誘導した後、ホームフォルダ変更と登録データベース追加を通じて偽のTCC.dbへ回避できる
- 実際にこの方法でテストし、TCCの動作に影響を与えられることを確認した
タイムライン
1.
- 2024-05-02 : Apple Product Securityに初回報告し、追加メッセージも送信した
2.
- 2024-05-03 : Apple Product Securityから追加説明の要請があり、回答した
- 同日、TCC全体の回避可能性を発見し、Appleに再報告した
3.
- 2024-05-04 : PoCテストを継続し、追加アップデートのメッセージを残した
4.
- 2024-05-06 : Apple Product Securityから情報提供への謝意があった
5.
- その後も随時、修正状況の問い合わせと状態確認を行い、2024-06〜2025-02まで継続的にAppleと連絡を取ったが、長期間修正されなかった
6.
- 2025-05-12 : 当該バグの修正がリリースされた
結論
その他の事項
- TCCはSystem SettingsアプリのPrivacy & Security（旧Security & Privacy）項目および該当するAutomationセクションに表示される
- しかしApple Events関連の同意履歴はGUIに表示されないため、ユーザーが直接取り消すのは難しい
- CLIツールの
tccutilでは取り消し可能だが、ほとんど知られていない
- 最近、Apple Endpoint SecurityフレームワークにTCCデータベース変更監視機能が追加された
- もし正常に動作するなら、実際に権限を得たアプリが何かをユーザーに知らせ、悪用防止に役立つ可能性がある
Appleの修正
- 実際の修正内容は複雑だが、外部から任意にindirect objectが指定されたメッセージはtccdで静かに無視されるよう変更された
- 動作確認の結果、もはやスプーフィングは不可能になったことを確認した
- もし修正が不完全なら、その後のアップデートで追加措置が必要になる可能性がある
最後に
- 本脆弱性には「TCC, Who?」という名前を付けた
- セキュリティ研究者の視点から、権限システムの信頼性が持つ重要性を改めて強調する
- 今後も類似の欠陥が見つかる可能性があることを示唆している
- ユーザーはmacOSの権限ポップアップを盲信すべきではないことを示している
1件のコメント
Hacker Newsの意見
Appleの誰かがこの記事を見るほんのわずかな可能性に賭けて、いつもお願いしたいことを繰り返しておく—Appleには「今すぐ（ローカル管理者の）パスワードを入力してください」というダイアログを、コンピュータがアップデートや何かのインストールをしたくなったという理由で、好き勝手なタイミングで突然出すのをやめてほしい。基礎的な技術があれば、Web上でほとんど同じ見た目の偽ポップアップを簡単に作れるし、技術的に上位20%くらいを除けば、ほとんどのユーザーはそれが本物なのか、ブラウザ内で作られた偽物なのか見分けようとすらしない。こういう問題を根本から防ぐには、正規のソフトウェアは何の予告もなく作業の途中でいきなりパスワードダイアログを出さない、という習慣をユーザーに身につけさせる必要があるが、現在のmacOSのセキュリティUIはその真逆だ。メニューバーにカラフルで目立つアイコンを表示するか、Windowsのように一瞬セキュアデスクトップを表示するなどの方式に変えるべきだ。今のUI設計は本当に問題が多い
こういうポップアップでいちばん嫌なのは、なぜこれを要求しているのか、拒否すると何が起きるのか、後からこの設定を変えたい場合に何をすればいいのかが、まったく分からないことだ。アプリが「設定パネルを開いてXXX権限を付与してください」と案内する方式なら、どのアプリの、どの権限の、どのトグルなのかが明確に見えるが、パスワードポップアップはそういうUXを提供しない。だから私は
capabilitiesという概念があまり好きになれなくなった。UXがひどく不便で、ほとんどどうしようもないからだ。「アプリを完全に使うには<root my computer>を許可してください」みたいな表示になるだろうし、ベンダーが文言を決めるならどうせこうなる。まったく役に立たないUXだmacOSが今でもモーダルウィンドウを各ウィンドウにひも付けて表示していたら、この現象は多少ましだった気がする。完全な解決にはならないが、今よりはよかったと思う。今のようにツールバーの上にモーダルが覆いかぶさると、一見して「アプリの内部」という印象を与えてしまう。Steve JobsもAquaのデモのとき、こうした独立して浮くモーダルは使い勝手を悪くすると強調していたのに、今はAppleがあらゆる画面でモバイルUIを使いたがる妙な執着のせいでこうなっている気がする
技術に詳しくない家族は、ローカル端末のパスワードとiCloud/Apple IDのパスワードの違いすら分からず、とにかくどれか当たるまで全部入力してしまう（UIが不明瞭で一貫していないせいだ）。Appleは昔VistaのUACを馬鹿にしていたが、今では自分たちも突然の通知と雑なUIを大量に作っている
最近LinuxからMacに移ってきたが、ランダムに出るrootパスワードのポップアップには本当に混乱した。どのアプリやコマンドがroot権限を要求しているのか、なぜ必要なのか説明が何もないので、何度か許可したあと、もう拒否に切り替えた。その後はポップアップが出なくなった。でも、何のために出ていたのか、なぜ出なくなったのかは今でもまったく分からない
もう一度この古典的な記事を勧めたい: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
PasskeyのポップアップはJavaScriptのポップアップとまったく見分けがつかず、セキュリティ上とくに深刻な失敗だ
こういう状況では、内蔵の指紋認証センサーが本当にありがたい。普段はノートPCを閉じて外部モニターだけで使っているが、システム認証が必要なときはわざわざ開いて指紋で認証している
どんでん返し: 実はそんなダイアログは最初から存在しなかった！ すでにだまされていたのだ
現時点でいちばん人気のあるコメントに便乗して伝えておきたい情報がある—この記事には重要な更新がある: https://news.ycombinator.com/item?id=43969087
偽ポップアップをクリックしたときの脅威モデルが何なのか気になる。実際にシステムのものではないなら、これには何の意味もない操作なのではないかと思う
iCloudにログインするときにコンピュータのローカルパスワードを要求するポップアップが出るが、それを入力するとそのパスワードがiCloudサーバーにアップロードされる
最近、MacアプリはシステムのApplicationsではなく、ホームディレクトリのApplications（~/Applications）にインストールすべきだと知った。もちろん、これは一人で使うコンピュータでのみ意味がある。自分自身を非管理者（non-admin）ユーザーにして、アプリをホームディレクトリのApplicationsにインストールすれば、アップデート時の権限要求に悩まされなくなる。大半のアプリは管理者でなくても自力で更新できる。例外として、TailscaleのようにOS統合が必要なアプリだけが別途権限を必要とする。ちなみに、Pareto Securityというアプリが勧めていた方法だ
残念ながら、ほとんどのアプリ開発者もこの方法を知らないし、多くのアプリはそもそも
/Applicationsにしかインストールできない前提になっていて、それ以外の場所では動作しない~/Applicationsにアプリをインストールすれば、rootなしで自動更新できるが、そのぶん怪しいコードもroot権限なしで簡単に上書きできるmacOS 15.4.1を使っているが、
~/Applicationsフォルダ自体がない面白い！ 私は普段adminアカウントが必須なのでこの方法は使いにくいが、当てはまる人には本当に有用な方法だ
この記事の内容には重要な訂正が必要だ。以前は、このCVEはmacOS Sequoia 15.5で修正されたと書かれていたが、実際には同日に公開されたmacOS Ventura 13.7.6とmacOS Sonoma 14.7.6には修正が適用されていなかった。Appleが当然すべてのバージョンに修正を入れているものと思い込んでそう書いたが、セキュリティリリースノートで私の名前がその2つのバージョンに載っていないのを確認し、Appleに直接問い合わせた。まだ返答はない。自分で検証するため仮想マシンを立ち上げ、macOS Sonoma 14.7.6にパッチを適用してPoCを実行したところ、依然として脆弱性は機能した。おそらくVentura 13.7.6も同様だと思う。Appleがなぜ修正を入れなかったのか理解できない。追加情報があれば、また記事を更新する予定だ
macOSのTCCシステムは堅牢なプライバシー機構として評判が高いが、実際にはデータベースの1エントリで簡単に回避できることを思うと、何ともやりきれない。ユーザー同意のポップアップは、実際のデータベース操作の前では大して意味がない。とくにSIPが無効な開発環境ではなおさらだ。結局これは信頼の問題だ。UX上の同意が、なお実質的なセキュリティ境界線なのか疑わしい。OSレベルの権限ポップアップにますます依存するようになっているが、その境界が実際には幻想（あるいは単なる演出）にすぎないのなら、権限への信頼を「どう見せるか」ではなく「実際にどう維持するか」を改めて考える必要がある
capabilitiesシステムが実装されるなら、はるかによいだろうという点には同意する。ただ、結局データベースならユーザー空間かカーネルのどちらかに保存するしかないというジレンマがある。とはいえ、どちらもあまり気持ちのよい案ではない昔の「I'm a Mac and I'm a PC」広告で、Vistaのこういう要素を嘲笑していたのを覚えている。なのに今では、自分のMacはVistaよりひどい。本当に腹が立つ
セキュリティと拡張性のトレードオフは避けられない宿命のようなものだ。それでも、基準線が昔より移動したという面もある。少なくともmacOSは昔のWindowsのように悪性プロセスだらけではない。あるいは、私が運よく慎重だからそう見えるだけかもしれない
単なる興味で聞くが、何がそんなに特に腹立たしかったのか知りたい
TCCシステムは最初から穴だらけの設計だった。正規の開発者だけを苦しめ、ユーザーには権限要求ポップアップを浴びせる一方で、悪意あるアプリは研究者が繰り返し明らかにしているように、さまざまな経路でこの「セキュリティ（ショー）」を回避してしまう。私はセキュリティ研究者ではないが、Mac開発者として自分でも複数の回避方法を見つけた。Appleのエンジニアたちが、自分たちの使っている技術を本当に理解しているのかさえ疑わしい。昔ながらのMac開発者がいったい何人残っているのか気になる
会社のMacを使っているのだが、定期的に「Slackが新しいヘルパーツールをインストールしようとしています」という通知が出る。これが何なのか、なぜ出るのかまったく分からない。ITチームに聞いても確認方法が分からなかった。悪用されうるとよく思っている。なぜなら、何度もパスワードを求めてくるし、毎回キャンセルしても出続けるからだ
そのダイアログはSystem Managementフレームワークから出ているものだ。Slackがどこにインストールされていても、どのユーザーが入れたものであっても、自分で更新できるように権限の高いヘルパーツールをインストールする過程だ
こういうポップアップが出るたびに、どんな情報を見て許可または拒否を判断すればいいのか知る手段がないので、いつもキャンセルしか押せない
SlackをWebアプリとして使っている（ただしブラウザ内ではなく、独立したウィンドウで） https://support.apple.com/en-us/104996 Discordも同じ方式で使える。体感としてElectronアプリよりずっと快適だ。たいていのElectronアプリはこの方式のほうがよい
私は「ヘルパーツール」ポップアップを実際に見たことはないが、Slackのような単純なメッセージングアプリに、なぜそんな権限が必要なのか理由が分からない。Slackのサポートに問い合わせるのがよいと思う（そして、ちゃんとした答えが返ってくることを願う）
パスワードを必要とするアプリ（たとえばLinuxでrootでしか実行できないバイナリ）と同じで、悪用の可能性は確かにある。結局は、開発者とそのアプリが本物で信頼できるかどうかの問題だ。Appleが外部アプリにroot権限をまったく与えられないようにする日が来たら、それはMacが完全な閉鎖型（walled garden）になる日であり、ここ（HN）には不満のコメントがあふれるだろう。要するに、Slackのように明確な必要性がないアプリにはroot権限を与えないという「健全な不信感」を持つことが重要だ
入力フォーカスを強制的に奪われて、メッセージ入力中だったテキストが突然パスワード入力欄に打ち込まれ始める。非常に腹立たしい体験だ
ポップアップが時間差でたまっていく。週末のあとにコンピュータを起動すると何度も繰り返し表示されるので、結局Slackを終了する。もう1年この状態だ。Slackからこの権限をどう取り消せばいいのか分からず、少し悪質に感じる
こういうタイプの「セキュリティ」ブロック機構は本当に愚かだ。むしろ人をもっと愚かにする訓練になっている。今日は本物でも明日はそうでないかもしれない。銀行から「本人確認の保護」の名目で私の個人情報を求める電話が何度も来るが、こういう仕組みは結局、見知らぬ相手に個人情報を渡すよう人を訓練してしまう
macOS開発者ではないが、どんな（悪意ある）アプリでもシステムのポップアップウィンドウの見た目を真似して、ユーザーのパスワードを盗めるのか気になっていた
VSCodeも会社支給のMacで同じポップアップを出す。もう何年も無視している
Electronベースのアプリでは、OSのユーザーアカウントを複数使うとこういうポップアップが出る
nordVPNでも同じ現象が起きる
Appleがパッチを出すまで丸1年かかった。かなり長く感じる。<i>2024-05-04 複数の更新メッセージを残した、PoCを継続テスト中</i> <i>2025-05-12 パッチがリリースされた</i>
Adobe Creative Cloudは、OS設定で明示的にバックグラウンド実行を無効にしても、複数のプロセスをバックグラウンドで動かし続ける
この人の研究は本当に好きだし、発表もとてもうまいと思う