修復中のエラーを修正する方法

2026-Oct-06 Natalie Silvanovich

Project Zero は、報告した脆弱性の修正でソフトウェアベンダーと協力することが多く、ソフトウェアをより安全にするための幅広い指針も提供している。ベンダーの中には、脆弱性がユーザーに実害を与えている最中で、しかもパッチ配布システムがその要求に応えられない場合、修正を完了できないのではないかと懸念する向きがある。ベンダーとのやり取りやセキュリティレビューを通じて、Project Zero は異常な悪用シナリオでユーザーを保護するためのさまざまなシステムを見てきた。そこで、そこで得た知見をいくつか共有したい。

本記事では、大手ベンダーが採用しているシステムのうち、通常の更新プロセスよりはるかに速く少数の脆弱性を修正できるものの概要を述べる。狙いは、こうしたシステムの構築や強化を検討するベンダーの参考になること、そして緊急の脆弱性を受け取る前に、自分たちがどう修正するのかをベンダーに考えてもらうことにある。

パッチ適用に時間がかかる理由

脆弱性の修正は通常、次の段階を経る。

トリアージ——脆弱性報告を受け取り、検証と優先度付けを済ませ、修正担当の開発者を割り当てる
パッチ開発——ソフトウェア開発チームが脆弱性を修正するコードを書き、レビューし、コミットする
テスト——パッチが脆弱性を解消したか、パッチ適用後もソフトウェアが正常に動作するかを検証する。テストチームによる正式なテスト、自動テスト、少数のユーザーにパッチを配信して通常利用のフィードバックを集める alpha テストや beta テストが含まれることもある。
パートナーによるレビュー——ソフトウェアベンダーと他組織との関係上、一部のソフトウェア更新はリリース前に第三者のレビューを必要とする。たとえばモバイル向け更新の一部は通信事業者の承認が必要だ。
配布——パッチがエンドユーザーに届き、インストールされる
有効化——更新後のソフトウェアに切り替えるために、システムの再起動など追加の手順が必要になることがある

もちろん、これは単純化した図式にすぎない。パッチ適用では、テスト失敗後にパッチを書き直す、サードパーティベンダーが絡んで追加の段階が生じるなど、工程が繰り返されることがある。それでも、ほとんどのソフトウェア更新に必要な最小限の手順はこれで尽きている。

緊急パッチの難しさ

トリアージとパッチ開発にかかる時間は、ベンダーが通常どれくらいの速さで脆弱性を修正できるかを大きく左右するが、緊急パッチの所要時間への影響は小さい。緊急の問題だと分かっていれば、トリアージはたいてい非常に速く、パッチ開発も優先度に応じて加速できる。トリアージや開発の段階で緊急パッチが滞るのは、ごくまれなケース——脆弱性が特に複雑なとき、あるいはベンダーのセキュリティチームが自社ソフトウェアのコンポーネントと、組織内でそれを保守している担当者を把握しきれていないとき——に限られる。同様に、パートナー契約にも緊急時の更新に関する例外条項が設けられているのが普通だ。

多くのベンダーでは、パッチの速さはテストと配布の段階で頭打ちになる。テストが重要なのは、ソフトウェアへの変更はどんなものでも予期しない挙動を持ち込みうるからだ。最悪の場合、テストが不十分なソフトウェアがデバイスを「文鎮化」させ、正常に動作しなくなる。重要な機能を実行できず、修正のためのソフトウェア更新を受け取ることもできない。欠陥のあるソフトウェア更新がユーザーデータの破損や消失を招いた例もあり、セキュリティ更新の後にソフトウェアの機能が何かしら低下すれば、ユーザーは将来いっそう更新をインストールしなくなる。

テストが不十分な更新をリリースしたときにベンダーが払う代償は、対象ソフトウェアの性質によって変わる。たとえばモバイルアプリが、更新でローカルデータを壊したり起動できなくなったりして使えなくなった場合、ユーザーはアプリストアから次のバージョンを簡単にインストールできるし、データも通常はリモートサーバーに保存されているので、代償はユーザーサポートにとどまる。これに対しモバイルデバイスが文鎮化すると、メーカーや購入先に送って修理する必要があり、ベンダーにもユーザーにも相応のコストがかかる。

ほとんどのパッチ配布システムは、重大な機能バグが起きうることを前提に設計されている。更新はしばしば少しずつ段階的に配信され、深刻な問題が多くのユーザーに影響する前に発見できるようになっている。脆弱性を素早く修正することと、バグのあるパッチを配信しないことはしばしば衝突する。どちらを優先するかのトレードオフが生じる。

パッチ配布を遅くする技術的な難しさもいろいろある。ひとつはパッチシステムの設計だ。よくある設計では、デバイスが一定間隔で更新をポーリングするため、パッチの到達率はその間隔に縛られる。「プッシュ」型の更新システムなら全ユーザーにはるかに速くパッチを届けられるが、通常はより多くのインフラを要する。

ユーザーの行動や利用環境もパッチの普及を妨げうる。インストールにユーザー操作が必要なパッチは後回しにされがちで、回線速度やデータ通信費もインストール率に影響する。一度に大量のユーザーを更新する（一定期間に分けて配信するのではなく）と、パッチ配布インフラに負荷がかかる。Chrome と Microsoft はそろって記事を書き、インストールに再起動が必要な更新の難しさに触れている。ユーザーはシステムの再起動を嫌いがちで、再起動そのものにも時間がかかるからだ。

テストの遅延とパッチ配布システムの制約はあらゆる更新に影響するが、緊急更新は時間の窓が短いぶん、パッチが届くまでの総時間に占める割合が大きくなる。

緊急時の修正手法

フィーチャーフラグ

フィーチャーフラグはソースコード中の条件分岐で、その枝はリモートサーバーが提供する値で決まる。A/B テストによく使われるが、緊急時には脆弱性の短期的な緩和にも使える。よく知られた例が 2019 年の FaceTime の重大な脆弱性で、Apple はフィーチャーフラグを使って Group FaceTime を一時的に無効化した。複数のベンダーが、少なくとも 0-click で発火しうるメディアコーデックの一部をフィーチャーフラグで制御するようにし、実際に悪用された際にはそれを無効化して、リアルタイム伝送を別のコーデックにフォールバックさせている。

フィーチャーフラグを脆弱性の修正手段として使う主な利点は、フラグの各状態をあらかじめテストしておけることだ。だから迅速な更新でも、テストされていないコードをリリースせずに済む。フラグの配信もはるかに速い。フラグの更新で転送するデータはごくわずかで済むからだ。

最近、Meta はブログ記事を公開し、2 つのバージョンの WebRTC ビデオ会議ライブラリを 1 つのバイナリにコンパイルし、フィーチャーフラグでどちらを使うかを切り替える「デュアルスタック」ライブラリの実装方法を紹介した。この手法により、迅速な更新に必要なテスト量を減らせる。新バージョンのリリース時に旧バージョンを使う選択肢を残しておき、機能に問題が生じたらすぐユーザーを旧バージョンに戻せるからだ。Meta は同一ライブラリの 2 バージョンを使っているが、同じ機能を実装した 2 つの異なるライブラリ（たとえば 2 つの H264 ライブラリ）で「デュアルスタック」を構築してもよい。そうすれば緊急時にアプリを別のライブラリへ切り替え、機能を一切失うことなく特定の脆弱性に到達できなくできる。追加のテストは必要だが、事前に済ませておける。ASAN や DCHECK の有効化のように性能オーバーヘッドの大きい緩和策を有効にするための 2 つ目のライブラリを用意し、多くの潜在的なバグを遮断するという使い方もある。

フィルタリング

フィルタリングとは、動的に更新できるルールセット（正規表現など）で信頼できない入力を検査し、ある脆弱性に到達するために必要な特定の入力を遮断する手法だ。Android の Intent Firewall がその一例で、動的に更新できる XML ファイルのルールに基づいて Android の IPC 機構である intent の特定の使われ方を無効化し、特定の脆弱性を引き起こすのに使える intent を遮断できる。これは最近、サードパーティ製 Android ウォレットの脆弱性を遮断するために使われた。

プラットフォームによっては、Windows の Microsoft Defender や Android デバイスの Google Play Protect のように、さまざまなシステム入力をフィルタリングできるエンドポイント検出ソフトウェアを備えている。特定の exploit を遮断したり、特定の脆弱性に到達できなくしたりするルールは、こうしたアプリに素早く配信できることが多い。エンドポイント検出は大量の信頼できない入力を解析する必要があり、しばしば特権コンテキストで動作するため、これらのアプリ自体にリスクがないわけではない。だが、すでに導入済みのシステムでは、緊急修復の有効な手段となる。

手段として見ると、フィルタリングはフィーチャーフラグより柔軟だ。フィーチャーフラグを機能させるには、どの機能を切る可能性があるかをベンダーが事前に特定していなければならない。検討が不十分だと、フィーチャーフラグでは修復できない脆弱性に陥りかねない。フィルタリングなら、これまで想定したことのないものを含め、多種多様な入力を遮断できる。欠点は、頻繁なフィルタリングがソフトウェアの性能を損なうこと、新しいフィルターには少なくとも一定のテストが必要で、どの脆弱性を遮断するのかが分からない段階ではそのテストを事前に済ませられないこと、そしてフィルターを書き間違えるとシステムに必要な機能を妨げるおそれがあることだ。

代替チャネル

ソフトウェア更新をユーザーに配信するネットワーク「チャネル」は、上述のさまざまな理由で遅くなりうる。ベンダーはときに、より小さな更新を迅速に配信するための代替チャネルを用意する。

Android Pony Express（APEX）はそうした代替チャネルの 1 つで、システム全体の更新より速く、Android 内の特定のリスクの高いコンポーネントに更新を届けられる。OEM が APEX コンポーネントの更新を統合する必要がなくなるため、パッチ開発の期間を短縮できる。APEX は OEM に開放されており、OEM が保守するライブラリの更新に使える。

我々が調査したアプリのいくつかは、通常の更新とは別に特定のライブラリを更新できた。やり方は概ね、フラグを立て、定期的にネットワーク経由で確認し、該当するライブラリをダウンロードして dlopen や同種の機構でロードするというものだ。更新配信速度の制約を回避する有効な方法ではあるが、こうして配信されるライブラリがクライアント側で十分に検証されず、ベンダー由来だと確認できなければ、深刻な脆弱性を持ち込むおそれがある。ベンダーは慎重を保ち、こうした緊急更新機構が十分なセキュリティテストを経ていることを確かめるべきだ。

ホットパッチ

一部のベンダーは、ライブラリより小さなバイナリコードの単位を実行中プロセスのメモリ空間に直接届けて適用する更新機構をすでに実装している。たとえば Linux は Livepatch をサポートし、再起動なしでカーネル関数をメモリ上で直接置き換えられる。Windows の hotpatch も同様で、更新する関数だけを含むパッチをユーザーに配信し、プロセスの実行中に適用できる。

ホットパッチは、ユーザー体験を損なわずに非常に柔軟なセキュリティパッチを極めて速く配信できる見込みがある。ただし配信できるパッチには性質上の制約がいくつかあり、たとえば関数間で共有される構造体定義の変更を要する更新はサポートされないことがある。セキュリティ上の欠点は代替更新チャネルと似ており、さらに脆弱性緩和策を回避されるリスクも伴う。パッチ適用の過程で、ある時点でページを書き込み可能かつ実行可能な権限でマップする必要があるからだ。迅速な更新のテスト上の難題も何ら解決しておらず、解決するのは配信の難題だけだ。

緊急パッチの重要性

LLM は攻撃者と防御者の双方で、脆弱性の発見と悪用の能力を高めつつある。今ではより多くの種類の主体が、より速い速度で新しい攻撃を仕掛けられる。これを踏まえ、ベンダーは脆弱性が実際に悪用されたときユーザーをどう守るかを考えなければならない。迅速な更新機構は重量級である必要はなく、あらゆるシナリオで考えうるすべてのバグを修正し、完璧なユーザー体験を保つものである必要もない。フィーチャーフラグ、フィルタリング、代替更新機構といった手法は、最も起こりやすく深刻な脆弱性を短期的に修復しつつ、デバイスをユーザーにとって最低限使える状態に保てる。

ベンダーは、最悪の状況——脆弱性が大規模に実際に悪用される事態——でユーザーをどう守るかを今すぐ計画する必要がある。今打てる手はユーザーの安全を大きく改善しうる。手元にある更新機構を洗い出し、欠けているところに迅速修復の仕組みを実装すれば、ベンダーは今後のあらゆる局面によりよく備えられる。

ゼロデイエクスプロイトを極めて困難にする。

プライバシー