昨年iMessageでゼロクリックの脆弱性に見舞われた後、Appleはプラットフォームのセキュリティを改善するために懸命に取り組んできたとGoogleのセキュリティ研究者Samuel Groß氏は書いている。iOS 14の主な変更点の1つは、BlastDoorである。BlastDoorは、すべての信頼できないメッセージの解析をする緊密にサンドボックス化されたサービスである。また、すべてのシステムライブラリを含む共有キャッシュ領域のランダム化の改善と、ブルートフォース攻撃に対抗するための指数関数的スロットルの使用も提供する。
Groß氏によると、新しいiMessageパイプラインには、メッセージ処理に関係する7つ以上の異なるサービスが含まれている。
複雑で信頼できないデータの処理の大部分は、新しいBlastDoorサービスに移されました。さらに、7つ以上の関連サービスを備えたこの設計により、きめ細かいサンドボックスルールを適用できます。
これにより、BlastDoorは非常に厳格なルールのセットを使用できる。一方で他のサービスではより緩いルールとなる。BlastDoorのルールは、diagnosticd、logd、opendirectoryd、syslogd、notifydなどの少数のサービスへのアクセスのみを許可する。また、ファイルシステムの相互作用を厳しく制限し、アウトバウンドネットワークアクセスとドライバーとの相互連携を完全に禁止する。
興味深いことに、BlastDoorがクラッシュするたびに、一部のAppleサーバに通知されているようである。Groß氏によると、サーバのコードにアクセスしないと、その情報がどのように使用されているかを判断するのは困難である。一方では、iMessageに対するいくつかの攻撃が行われている可能性があるという警告を提供する可能性がある。一方、攻撃者を混乱させる試みに関連しているようである。
私の実験では、これらのクラッシュ通知の1つを監視した後、サーバは、受信者によって実際に処理されていないメッセージの配信確認を送信者に直接送信し始めました。おそらくこれは、送信者を混乱させることによってクラッシュさせる技術を破るための、別の独立した取り組みです[...]
Groß氏は、Swiftを使用してBlastDoorを作成することの重要性も強調した。実際、Swiftの安全性保証により、システムの制御を奪うために悪用されることが多いメモリ破損の脆弱性が利用される可能性が低減される。しかし、BlastDoorは、libxmlを使用したXML解析とNSKeyedUnarchiverによるペイロードの復号化のためにObjective-Cで記述された古いコードにまだ依存している。
AppleがiMessageを強化した方法は、BlastDoor、サンドボックス、クラッシュモニタリングだけではない。前述のように、Appleは、プラットフォームのアーキテクチャ上の弱点の1つである共有キャッシュ領域の修正にも取り組んだ。
単一の事前リンクされたBLOBにほとんどのシステムライブラリを含む共有キャッシュ領域は、ブートごとにランダム化されるだけです。そのため、すべてのプロセスで同じアドレスに留まります。
これにより、攻撃者が共有キャッシュのベースアドレスを推測し、アドレス空間配置のランダム化を破ることが容易になっていた。これに対するAppleの修正は、クラッシュが検出された後には、攻撃されたサービスに対して、新しい再スライドされた共有キャッシュイメージを割り当てるカーネルベースのメカニズムを作成することであった。
iMessageをより安全にするための最後の対策は、指数関数的スロットルである。これは、サービスの改ざんの試みを制限し、ブルートフォース攻撃から保護することを目的としている。この場合、クラッシュが検出されたときに、クラッシュしたサービスにおいてlaunchd .plistファイルで_ExponentialThrottlingが有効になっていると、その再起動にかかる時間は指数関数的に増加する。Groß氏の実験結果によると、これは最大20分になる。共有キャッシュイメージの再スライドと同様に、これはプラットフォーム全体の機能であるが、現在はBlastDoorサービスでのみ使用されているようである。
Groß氏の記事には、新しいiMessageパイプラインとiOSとmacOSの新しいセキュリティ関連機能に関する興味深い技術詳細が豊富にあるため、全体像を把握するために目を通したほうがよいであろう。