MetaのMuseで報告された脆弱性は、強力なAIアシスタントにとって現実的な疑問を投げかける。ソフトウェアがアカウント、ファイル、アプリケーション、デバイスをまたいで動作できる場合、そのセキュリティ上の境界はどこに設けるべきなのか。Ars Technicaによると、macOSのセキュリティ研究者Patrick Wardle氏は、ユーザーアカウントの権限で実行されるコードが、文書化されていないMuseの設定を変更し、文字起こしを攻撃者に制御されたエンドポイントへ転送する方法を発見した。その後、Museがそのエンドポイントへデータを送信した際、ユーザーのMuseアカウントを認証するために使われていたトークンも露呈したという。
報告された影響は、単一の音声文字起こしデータへのアクセスよりも深刻だ。Ars TechnicaはWardle氏の実証実験に基づき、トークンを掌握した攻撃者が、Museに接続された権限を利用し、コマンドの実行、ファイルの書き込み、画像の取得、あるいはそのアカウントから利用可能なサービスとのやり取りを行える可能性があったと伝えている。これらは欠陥によって起こり得たことを示す実証例であり、実際に野外で悪用されたことや、多数のユーザーに影響が及んだことを示す証拠ではない。
Ars Technicaの掲載画像は、Metaの高権限AIアシスタント「Muse」の脆弱性に関する報告に添えられている。
この脆弱性とClickFixは関連しているが、同じものではない。ClickFixは、被害者を説得して信頼されたシステムツールに悪意のあるコマンドをコピーして実行させるソーシャルエンジニアリング手法だ。Ars Technicaが説明する根本的な問題は、権限を持たないローカルコードによる機密性の高いエンドポイントの変更を、Museが受け入れてしまう点にある。ClickFixを使えば、攻撃者が従来の管理者権限を事前に取得しなくても、そのコードを実行できる。しかし、ソーシャルエンジニアリング手法そのものがソフトウェアの脆弱性なのではない。
この画像は、ソーシャルエンジニアリングによって、ソフトウェアそのものの欠陥ではない方法でコードが実行され得る仕組みを説明している。
この区別は重要だ。ローカルで実行されたコマンドは、依然として攻撃経路の一部だからである。提示された証拠からは、遠隔地の攻撃者が、ユーザーの操作、マルウェア、ローカルコードを実行する別の手段なしに、改変されていないMuseのインストール環境を侵害できたと結論づけられない。また、この欠陥がどれほど頻繁に悪用されたか、影響を受けたインストール数がどれほどだったか、実在のアカウントが侵害されたかどうかは明らかになっていない。Wardle氏の実証実験が示したのは、特定の条件下で実行可能であるという点であり、広く悪用されていたという事実ではない。
Ars Technicaの補足ビジュアルは、Museの文字起こしを転送するローカルコードを実行する手段としてのClickFixに関する説明に添えられている。
Meta自身が公開したセキュリティに関する説明は、この報告が注目を集めた理由を理解する助けになる。「How We Built Safety Into Muse」でMetaは、各ユーザーに分離されたクラウド仮想マシンが割り当てられ、認証情報はエージェントの実行環境の外に保存され、ホスト側システムのSentinelだけがコネクタの操作とネットワーク外部への通信を承認する権限を持つと述べている。さらにMetaは、実行環境内のrootを権限のないホストユーザーに対応付け、機密性の高いサービスはエージェントのコンテナ外で実行されているとも説明している。これらは、当時公開されたシステムに対するMeta自身の説明であり、すべてのクライアント側境界を独立して監査した結果ではない。
Ars Technicaの報告は、文字起こしの発生場所を変更できるmacOSクライアントの設定に関するものだ。Metaの説明はクラウド仮想マシン、認証情報の分離、操作承認の仕組みに触れているが、提示された資料だけでは、この文書が、セキュリティ上重要なエンドポイントをローカルクライアントが設定できる点まで完全に説明しているとは確認できない。したがって、両資料はMuseの重複する側面を扱っているが、同じ実装上の詳細が正しいことも誤りであることも、それぞれ独立して証明しているわけではない。Metaのアーキテクチャに関する主張を、報告されたクライアント側の欠陥が起こり得なかったことの裏付けとして扱うべきではない。
クラウド上での文字起こしは、報告された仕組みの中心にある。Ars Technicaによると、Museは通常、文字起こしをMetaが運用するサーバーへ送信しており、攻撃はその送信先を攻撃者に制御されたものへ置き換えることで成立する。同報告は、macOS上でデバイス内処理を行う文字起こしであれば、この特定の経路を避けられた可能性があると論じている。提示された証拠には、文字起こしの品質、遅延、プライバシー管理、技術的な制約に関する比較がないため、Metaがそのアーキテクチャを選んだ理由や、デバイス内で処理する代替案が製品の要件を満たせたかどうかは判断できない。
報告が公開されてから12時間以上が経過した時点で、Metaは修正プログラムを公開したと述べた。提示された情報源は、修正版のバージョン、パッチの全体像、修正後のテスト結果を特定していない。したがって、ユーザーは、この修正プログラムに関する案内を、関連するすべての設定経路が塞がれたことを独立して確認したものではなく、Meta自身の声明として受け止めるべきである。また、この証拠から、MuseやAIエージェント一般について、決して安全にできないという広い結論を導くこともできない。
それでもこの事例は、メール、カレンダー、メッセージ、ショッピングアカウント、ファイル、カメラ、シェルへのアクセスを許可されたエージェントにとって、運用上の重要な原則を示している。クライアントソフトウェア自体が、信頼できる計算基盤の一部になるという点だ。ローカルプロセスが、これらの制御が機能する前に機密性の高い通信を転送したり、認証トークンを取得したりできるなら、リモートのサンドボックス内で認証情報を守っても不十分である。高権限のエージェントソフトウェアを実行するデバイスでは、信頼できない情報源から端末コマンドや設定手順を貼り付ける行為に、特に注意すべきだ。
この欠陥と同時に報告された別の出来事は、サービス提供者がこうしたエージェントを、ユーザー自身の手动操作ではなく、外部の主体として扱う場合があることを示している。Ars Technicaは、AmazonがMuseによる購入をブロックし、Museを利用規約に違反する許可されていないAIエージェントだと表現したと報じた。Amazonは、購入を行うサードパーティー製アプリケーションは、その過程を明示して運営し、サービス提供者が参加の可否を判断する決定を尊重すべきだと述べた。このポリシー上の判断は、セキュリティ上の欠陥が悪用された証拠ではない。しかし、別の信頼性とガバナンス上の課題を浮き彫りにしている。アカウントへのアクセス権があっても、接続されたすべてのサービスが、エージェントによって開始された操作を必ず認めるとは限らない。