Apple Screen Sharingの深刻な脆弱性—認証不要でroot権限を奪取

今回報告されたApple Screen Sharingの脆弱性は、非常に深刻なものです。macOSのScreen Sharingデーモン(screensharingd)において、SRP(Secure Remote Password)フレーム長の検証処理に認証前(Pre-authentication)のリモートコード実行(RCE)脆弱性が存在することが明らかになりました(出典)。これは、攻撃者がパスワードも有効なユーザー名も知らずに、リモートからroot権限で任意のファイルを読み書きし、最終的にコードを実行できるというものです。

認証なしでリモートからroot権限でのファイル読み書き、さらにはコード実行が可能になるというのは、現代のセキュリティ環境においては看過できない脅威です。

具体的には、デーモンが特定の長さ(32768バイト以上)のSRPフレームを受信した際、「フレームが大きすぎる」というエラーパスで、以前の4バイト読み取り時の成功ステータス(ゼロ)が誤って返されてしまいます。これにより、呼び出し元が「認証完了」と誤解し、鍵交換や暗号化が行われないまま、認証後のメッセージループに入ってしまうという仕組みです。この認証バイパス後、攻撃者はApple独自のファイルコピープロトコル(メッセージタイプ0x22)を悪用し、root権限で任意のファイルを操作できるようになります。

脆弱性の詳細と影響範囲

この脆弱性は、macOS 26.5(Tahoe)以前の、SRPセキュリティタイプ36を持つすべてのバージョンに影響します。AppleはmacOS 26.6(2026年7月27日リリース)でこの問題を修正済みとのことです。

項目 詳細
影響ソフトウェア macOS Screen Sharing (screensharingd)
脆弱なバージョン macOS ≤ 26.5(Tahoe)—SRPセキュリティタイプ36を持つ全バージョン
修正済みバージョン macOS 26.6 (2026-07-27)
コンポーネント screensharingd SRPフレームリーダー
プロトコル Apple Screen Sharing (RFB 003.889), security type 36
認証要件 不要—認証前(Pre-authentication)
結果 認証前rootファイル読み書き—rootとしてのコード実行
SIPへの影響 認証バイパスとファイル読み書きはSIPの有無に関わらず機能。/etc/sudoers.d/+や/etc/zshenv経由でのRCEはSIP有効時にも動作。crontabインジェクションにはSIP無効が必要。
確認済み環境 Mac mini M4, macOS 26.4.1, arm64, SIP有効

この影響を見ると、SIP(System Integrity Protection)が有効なシステムであっても、一部のRCE経路は動作する点が特に懸念されます。自分の使っているMacは大丈夫か、すぐに確認したくなりますね。

攻撃の仕組みと対策

攻撃者は、たった一度のパイプライン接続でリバースシェルペイロードとrootのcrontabを注入し、認証されていない状態で60秒以内にroot権限でのリモートコード実行を達成できるとされています。ユーザーによる操作は一切不要であり、Screen Sharingが有効になっていることだけが前提条件です。パスワードも有効なユーザー名も、対象の設定に関する知識も必要ありません。

これはかなりの衝撃的なニュースだと感じます。普段からScreen Sharingを使っている開発者の方も多いのではないでしょうか。私も個人プロダクトのリモート操作で使うことがあるので、すぐにでも確認してアップデートを適用する必要がありそうです。

今回の脆弱性は、システムが外部に公開しているサービスが持つプロトコル処理の不備を突く典型的な例と言えます。日頃から不必要なサービスは停止し、必要なサービスも常に最新の状態に保つことが重要であることを改めて認識させられますね。

広がるサイバー脅威とAIの役割

このような脆弱性は、現代のサイバーセキュリティ環境の複雑さを浮き彫りにしています。最近では、ロシアの諜報機関が公共Wi-Fiをマルウェア配信システムに変えているという報告もありました(出典)。ホテルの会議室など、公共の場でのWi-Fi接続には注意が必要だということです。

さらに、AIがサイバー攻撃の「武器」と「標的」の両方になっているという分析も出ています(出典)。CrowdStrikeのレポートによると、2025年にはAIを利用した攻撃が89%増加したとのこと。

攻撃者はAIを使って攻撃チェーン全体を強化し、同時に組織のAIインフラや人気のあるソフトウェアパッケージを標的にしています。AIモデルがテスト環境からハッキングを試みる事例も報告されており(出典)、AIの進化は新たなセキュリティリスクをもたらしていると言えるでしょう。

これらの動向を見ると、単一の脆弱性対策だけでなく、より広範なセキュリティ意識と多層的な防御が求められていると感じます。自分の自宅サーバーや個人プロダクトでも、AIを活用したセキュリティ監視などを導入する時期に来ているのかもしれません。

開発者として取るべき具体的な対策

このような脅威に対して、私たち開発者はどのように対応すべきでしょうか。まず、今回のApple Screen Sharingの脆弱性に関しては、速やかにmacOSのアップデートを適用することが最優先です。

  1. macOSのアップデート:お使いのmacOSがmacOS 26.6未満の場合は、直ちに最新バージョンにアップデートしてください。システム設定から「一般」→「ソフトウェアアップデート」で確認・実行できます。
  2. Screen Sharingの無効化:もしScreen Sharing機能を使用していないのであれば、システム設定の「一般」→「共有」からScreen Sharingを無効にすることを強くお勧めします。これは不必要な攻撃経路を減らす基本的な対策です。
  3. ネットワーク境界の保護:ファイアウォールやルーターの設定を見直し、Screen Sharingが外部から直接アクセスできないように制限することも有効です。VPN経由でのみアクセスを許可するなど、よりセキュアな経路を検討してください。

これはうちのスクリプトで自動でチェックする機能とか作っておきたいですね。定期的なバージョンチェックと、もし脆弱性があったら通知してくれるような仕組みがあれば、忙しい中でも忘れずに対応できるのではないかと思います。Claude Code に投げてみたら案外すぐ動きそうな予感がします。

広範なセキュリティ対策としては、

  • 多要素認証(MFA)の導入:パスワードのみに依存しない認証を導入する。
  • 最小権限の原則:必要最小限の権限のみを付与し、root権限での操作は極力避ける。
  • 定期的なセキュリティ監査:自身の開発環境や個人プロダクト、サーバーの設定を定期的に見直し、脆弱性がないか確認する。
  • 情報収集:最新のセキュリティ情報を継続的に収集し、迅速に対応できるよう準備しておく。

といった基本的ながら重要な項目を徹底することが求められます。