CrowdStrike障害（2024）— 850万台のBSOD

何が起きたか（日時・影響範囲）

2024年7月19日 04:09 UTC、CrowdStrikeはEDR「Falcon」のWindowsセンサー向けに、検知設定データ Rapid Response Content を配信した。対象は名前付きパイプ悪用の検知を担う Channel File 291。受信したセンサー7.11以降のホストでは、カーネルドライバ（csagent.sys）が領域外読み取りで回復不能な例外を起こし、ブルースクリーン（BSOD）に落ちた。センサーはブート開始ドライバとして起動初期にロードされるため、再起動しても同じファイルを読んで再びクラッシュする。単発のBSODではなくブートループである。

影響はMicrosoft推計で約850万台（全Windows端末の1%未満）。だが基幹系での採用が多く、世界で5,000便超が欠航し、病院の手術・予約、銀行、放送、緊急通報まで停止が波及した。撤回は05:27 UTC——露出はわずか78分で、史上最大級のIT障害になった。

タイムライン

• 2024-02-28: センサー7.11リリース。IPCテンプレート型を新設。型定義は入力パラメータ21個——不整合がここで潜伏
• 03-05: 型がストレステストを通過し、最初のIPCテンプレートインスタンスを Channel File 291 で配信
• 04-08〜04-24: 追加インスタンス3件を配信。無事故が「この型は安全」という誤った確信を積み上げる
• 07-19 04:09 UTC: 新規2件を配信。うち1件が21番目のフィールドに初めて非ワイルドカードの一致条件を指定。受信ホストが順次クラッシュ
• 07-19 05:27 UTC: 配信撤回。以降に接続したホストは影響なし
• 07-19以降: セーフモード／WinREで該当ファイルを削除する手動復旧。BitLocker回復キーの取り出しがボトルネックに
• 08-06: 公式RCA公開

根本原因の技術解説

Falconの検知は「センサー本体（コード）」と「Rapid Response Content（データ）」の2層構造で、コンテンツはテンプレートインスタンスとして配信され、センサー内蔵のテンプレート型へパラメータを与え、カーネル内の Content Interpreter が解釈する。

不整合は型の導入時点で作り込まれていた。IPCテンプレート型は一致条件フィールドを21個定義したのに、Content Interpreter へ実行時入力を渡す統合コードは20個しか供給していなかった。2月から7月まで無事だったのは、既存インスタンスもテストも21番目が常にワイルドカードで、比較が短絡され21番目の入力値が一度も読まれなかったからだ。

inputs = sensor_supplied_values      # センサーが渡す入力は20個
rules  = template_instance.criteria  # 一致条件は21個

for i in 1..21:
    if rules[i] == WILDCARD: continue   # 従来は i=21 が常にここを通過
    match(inputs[i], rules[i])          # i=21: 入力配列の終端を越える読み取り

7月19日のインスタンスが初めて21番目に具体値の照合を要求した瞬間、Content Interpreter は存在しない21番目の入力を読みにいき、入力配列の終端を越えた領域外読み取り（out-of-bounds read）が発生。カーネルモードの不正メモリアクセスは回復不能で、OS全体が停止する。ユーザー空間ならプロセス1個の異常終了で済む欠陥である。さらにネットワーク初期化前にクラッシュするため修正コンテンツの自動取得が間に合わず、復旧は原則「セーフモードで手動削除」になった（再起動の繰り返しで取得が先行する競合が稀に勝つため、複数回再起動も案内された）。

なぜ防げなかったか

横にスクロール

ゲートは存在した。しかし全ゲートが同じ穴を素通しした。

決定的なのは最終行だ。センサー本体の更新は段階配布され、顧客はN-1/N-2版に留める運用もできた。だが Rapid Response Content はその規律の外で、顧客に受信を制御する手段がなかった。「データだからコードより安全」という暗黙の想定がカナリアもリングも省かせた。さらにバリデータは「センサーが実際は20個しか渡さない」という消費側の事実を知らず、生成側の定義だけを基準に検証していた。スキーマの単一の真実が無かったのである。

教訓（原則として一般化）

• コンテンツもコードと同じ配備規律で扱う。実行時挙動を変えるものはすべてデプロイであり、カナリア→リング拡大→自動ロールバックと顧客側の制御を備える。CrowdStrikeもRCA後にコンテンツの段階配信と顧客制御を導入した。段階的デリバリーの一般論はDevOpsの原則そのものだ。
• バリデータ自体を検証する。単一ゲートへの全面依存は、そのゲートのバグを全系のバグにする。生成側と消費側のフィールド数定義を単一ソースから導出し、実機での消費テストを併置する。
• カーネルに入るデータは敵対的入力として扱う。境界チェックと、失敗時はクラッシュでなく機能縮退へ倒す設計。CrowdStrikeも Content Interpreter への境界チェック追加と独立第三者によるレビューを対策に挙げた。
• カーネル依存を最小化する。特権空間に置くロジックが小さいほど、データ起因の欠陥が全損へ化ける面積は減る。ユーザー空間との分離はOSの基本原則であり、本件を機にMicrosoftとセキュリティベンダーはカーネル外で動く保護機構の検討を本格化させた。