macOSの信頼済みアプリ差し替え、MyskがGatekeeperの盲点を報告
MyskのTalal Haj Bakry氏とTommy Mysk氏は、Webから入れたmacOSアプリの実行ファイルを、初回起動後にユーザー権限だけで差し替えられる挙動を報告しました。Appleはこれをセキュリティ修正が必要な問題とは見なしていません。読みどころは、Gatekeeperが破られたという単純な話ではなく、ユーザーが一度信頼したアプリ名とアイコンが、次の許可判断にも使われ続ける点です。
一度信頼したWeb配布アプリが焦点になる
Myskの説明では、対象はMac App Storeから入れたアプリではなく、Webからダウンロードして一度起動済みのアプリです。例としてSignalが使われていますが、Signal固有の脆弱性ではありません。研究者は、Brave、Cursor、Mullvad Browser、Proton Mail、Slack、Visual Studio Code、Xcodeなど、Web配布のアプリにも同じ考え方が及ぶとしています。
手順の核は、アプリバンドルをtarでアーカイブし、元のバンドルを削除して復元することです。その後、`Contents/MacOS/`配下のメイン実行ファイルを置き換えても、macOSは改めてGatekeeperの警告を出さず、アプリは元のもののように起動します。研究者は、macOS Tahoe 26.0.0から26.5.2、macOS Golden Gate 27 beta 1から4で確認したとしています。
本当の危険は許可ダイアログの見え方にある
この挙動は、TCCやKeychainの保護を直接すり抜けるものではありません。差し替えられた実行ファイルがDesktop、Documents、Keychainへ触ろうとすれば、macOSは通常どおり許可を求めます。問題は、そのダイアログがアプリバンドル内の名前とアイコンを使うため、利用者には本物のSignalなどからの要求に見えることです。
つまり危険の中心は、技術的な署名検証だけでなく、許可画面の言語にあります。ユーザーは「このアプリを信頼してよいか」をアプリ名とアイコンで判断しがちです。そこに、実際に要求している実行ファイルの署名者やTeam IDが出なければ、信頼済みアプリを装った要求と本物の要求を区別しにくくなります。
Appleは仕様境界として扱った
Myskによると、Appleはこの報告を、GatekeeperやTCCのバイパスではなく、ユーザー所有ファイルの置き換えと許可承認の問題として扱いました。攻撃には、すでにユーザー権限でコードを実行できる状態が必要で、差し替え後の実行ファイルも既存のTCC権限やエンタイトルメントを引き継ぐわけではありません。
一方で研究者は、バンドル変更時の再検証や、許可ダイアログへのコード署名情報の表示を提案しています。Interface Wireとして見ると、ここはMacの安全性を「警告が出るか」だけで測れない例です。信頼のUIは、どのアプリ名を見せるかだけでなく、いま実際に権限を求めているコードが誰のものかまで示せるかに移り始めています。
関連記事
この報告は、すべてのMacがすぐ危ないという話ではありません。ただ、アプリ名とアイコンに寄せた許可画面が、ソフトウェア配布と攻撃手順の変化にどこまで耐えられるかを問うています。Mac App Storeか開発元から直接入れる、未知のスクリプトを動かさない、許可ダイアログを急いで承認しない。地味な習慣が、今回のような「信頼済みに見える」攻撃面ではかなり重要になります。