# たった1件のDarwin通知で露呈したiPhoneのサービス拒否攻撃経路
発生日:2025年4月27日
研究者ギー・ランボによるセキュリティ関連の解説記事によると、多くの開発者が直接使うことのないAppleの旧来のメッセージング機構が、iPhoneを端末レベルでサービス拒否状態に陥らせる経路になり得ることが分かった。しかも、その一つはたった1行のコードで発動できたという。
ランボの説明は、Appleプラットフォーム上のプロセス間で単純なメッセージを交換するために使われるCoreOSレベルのAPI、Darwin通知を中心としている。単一プロセス内にとどまる`NSNotificationCenter`とは異なり、Darwin通知はプロセスをまたいで送信、監視できる。ランボは、サンドボックス化されたアプリが特別なエンタイトルメントなしにこれらの通知の登録と送信の両方を行えると指摘する。このため同APIは正当なシステム連携に有用だが、悪用される可能性も生じる。
彼が検証しようとしたのは、まさにその可能性だった。投稿によると、彼は初期のiOS 18ベータ版のルートファイルシステムを調べ、`notify_register_dispatch`と`notify_check`を使用しているプロセスを探した。そのうえで、通知により動作する何らかのシステム挙動をアプリのサンドボックス内から強制的に起こせるかどうかを検証するため、EvilNotifyというテストアプリを作成した。彼によれば、答えはイエスだった。
彼が説明する中で最も深刻だった挙動は、ある通知によってSpringBoardが「復元処理中」の状態に移行するというものだった。ランボの説明では、この通知は通常、接続されたコンピューターを介してローカルバックアップから端末を復元する際に使われるものだが、どのプロセスからでも送信できた。その結果、システム全体が中断され、発動させたアプリを強制終了するだけでは解除できなかった。実際には復元処理が行われていないため、端末は最終的にタイムアウトし、その後ユーザーは「再起動」ボタンをタップしなければならず、それによって端末が再起動した。
ランボによると、このエクスプロイトが注目に値するのは、システム全体に影響したからだけでなく、発動条件が極めて小さかったからでもある。たった1行のコードで端末を復元状態に移行させることができたという。また、通知を監視してユーザーインターフェースを表示していたコンポーネントはSpringBoardだったとも述べている。
投稿ではさらに、再起動をまたいでこの効果を繰り返させる試みについて説明している。iOSアプリはバックグラウンド実行が制限されているため、ランボは再起動後にアプリ拡張機能から通知を再送信できるかどうかを調べた。彼はウィジェット拡張機能を選び、VeryEvilNotifyという2つ目のアプリを作成した。ウィジェットはプレースホルダー、スナップショット、タイムラインのためにシステムから定期的に実行されるため、インストール直後または再起動直後に再びコードを実行させる手段として現実味があると彼は述べている。
解説記事によると、ウィジェット拡張機能は、同じ通知ベースのロジックを実行する別の経路となった。投稿は端末を恒久的に使用不能にできることが確認されたとは主張していないが、端末を望ましくない復元フローへ繰り返し強制的に戻し、そのたびに手動での介入を必要とさせ得る一連の手順を説明している。
記事が示すより広い論点は、見出しから受ける印象よりも限定的だ。Appleが公開しているプロセス間通知システムは無害な連携を目的としているが、サンドボックス化されたどのプロセスからでも送信できるメッセージを、強力なシステム挙動が受信する設計になっている場合、同じ仕組みがサービス拒否攻撃の余地を生み出し得る。ランボはこの発見を、あまり知られていない旧来のAPIであっても、現代のiOSソフトウェアに極めて大きな影響を及ぼし得ることを示すものと位置づけている。
開発者にとって、この報告はプロセス間シグナリングが単なる実装上の細部ではないことを改めて示している。公開通知によって、特権的な処理やユーザーを混乱させるワークフローが発動するのであれば、その通知を送信できるあらゆるアプリを脅威モデルに含める必要がある。ランボの説明は、その通知がシステムUIや再起動の経路と結び付いている場合、リスクが仮定上のものではないことを示している。
投稿では、Appleが公式な対応を発表したとは記されておらず、この解説記事は、パッチ適用が確認されたとの発表ではなく、研究者による技術的な開示として提示されている。いずれにせよ、重要な結論は同じだ。旧来の通知が一つあるだけで、ユーザーが求めていない状態へiPhoneを導くには十分になり得る。



