CrowdStrike 2024年配信した設定による Windows の一斉停止

攻撃ではない。検知の規則として配った設定が、カーネルの中の部品に、用意された20個の入力の21個目を読ませた。確かめの仕組みは21個ある前提で通し、配信は段階を踏んでいなかった。止める所は、1つの定義から確かめと実装を作ること、使う時の境界の確かめ、段階的な配信、届いた後に戻せる備えにある。

CrowdStrike Falcon の Windows のセンサー 7.11 以上で、2024年7月19日 UTC 04時09分から05時27分の間にオンラインだった端末が対象。macOS と Linux は対象外[1][2]。CrowdStrike は攻撃によるものではないとした[1]。7月29日の時点で、Windows のセンサーのおよそ99%が更新の前と同じくオンラインに戻った[3]。境界の確かめを足したセンサーの修正版は、8月9日までに出すとされた[3]。2026年11月時点の公開資料で書いています。

要点

名前付きパイプの悪用を見る規則の型は21の入力の欄を定義していたが、センサーのコードは20の値しか渡していなかった[3]。
それまでの規則は21番目の欄に何でも合う条件を入れていたため、食い違いは表に出なかった。7月19日の規則が初めて21番目に具体の条件を置いた[3]。
配る前の確かめの仕組みは、21の入力がある前提で判断し、規則を通した[3]。カーネルの中で配列の外を読み、Windows が止まった。
Microsoft は影響を受けた端末をおよそ850万台、全部の Windows の1%未満と見積もった[4]。Microsoft の復旧の道具は、端末ごとに起動の媒体か安全な起動から入り、元のファイルを消す形だった[5]。
CrowdStrike は、規則の配信を段階にする、顧客が届く時と先を選べるようにする、境界の確かめと欄の数の確かめを足す、を挙げた[2][3]。

何が起きたか

図1 食い違いが入ってから表に出るまでと、その後

日付	出来事
2024年2月28日	センサー 7.11 を一般に出す。名前付きパイプなどの、プロセスの間の通信の悪用を見る新しい規則の型が入る[2]。型の定義は21の入力の欄を持ち、センサーのコードは20の値を渡す[3]
2024年3月5日	規則の型が試験の環境で負荷の試験を通り、最初の規則を本番に配る[2]
2024年4月8日から24日	同じ型の規則を、さらに3つ配る。期待どおりに動く[2]
2024年7月19日 04時09分 UTC	同じ型の規則を2つ足した更新を配る。1つが21番目の欄に何でも合う条件でない条件を置いていた[2][3]
2024年7月19日 05時27分 UTC	問題の更新を取り下げる[1][2]
2024年7月20日	Microsoft が、影響はおよそ850万台の Windows の端末と公表する[4]。同じ日に、起動の媒体から直す復旧の道具を出す[5]
2024年7月24日	CrowdStrike が速報の振り返りを出す[2]
2024年7月25日	規則の解釈の部品に、入力の配列の境界の確かめを足す[3]
2024年7月27日	規則の型が渡す入力の数を、センサーの組み立ての時に確かめる仕組みを、社内の組み立ての道具に入れる[3]。Microsoft が、セキュリティの製品はカーネルで動く部分を小さくするよう勧める[6]
2024年7月29日	Windows のセンサーのおよそ99%が、前の週と比べてオンラインに戻る。ふだんの週ごとの変動はおよそ1%[3]
2024年8月6日	CrowdStrike が根本の原因の分析を出す[3]
2024年9月10日	Microsoft が、セキュリティの製品の会社と米国と欧州の政府の担当を集めた会合を開く。段階的な配信を共通の原則とすることを話し合う[7]

Microsoft の7月20日の記事は、更新を7月18日に出したと書く[4]。CrowdStrike の時刻は UTC の7月19日04時09分で、米国の時刻では18日の夜に当たる。
被害を受けた組織の数、止まった業務、損害の額は、CrowdStrike と Microsoft の発表には無い。

起きた仕組み

図2 2つの「入力の数」が食い違ったまま、確かめと実行に分かれていた

段	何があったか
型	規則の型は、センサーの版に組み込まれ、何個の入力をどの種類で使うかを定義のファイルに持つ。規則は型に合わせて書かれ、チャネルファイルで配られる[3]。定義のファイルは21の欄を持ち、センサーのコードは20の値を用意した。この食い違いは、組み立ての時に確かめられていなかった[3]。
試験	型の自動の試験は12の場面で、試験用の規則は全部が21番目に何でも合う条件だった。だから試験では21番目を読まず、配列の外を読む誤りは出なかった[3]。
確かめ	配る前の確かめの仕組みは、定義のファイルに照らして規則を確かめる。定義が21個と言うので、21番目を使う規則を正しいと判断した[3]。CrowdStrike は、これまでの試験と確かめの仕組みへの信頼と、それまでの配信の成功から、規則を本番に出したと書く[2]。
実行	次の通知で規則が評価され、解釈の部品が20個の入力の配列の21番目を読んだ。そこは有効なメモリを指しておらず、配列の外の読み出しで止まった[3]。Microsoft の分析も、CrowdStrike の部品の中の配列の外の読み出しとした[6]。
配信	規則は、センサーの版と違い、雲から配られる[2]。根本の原因の分析は、規則を段階的に配るべきだったことを所見の1つに挙げ、対策として段階を足した[3]。

NULL の参照ではない

直後に広まった説明に、NULL ポインタの参照で止まったというものがある。根本の原因の分析には、そうは書かれていない。分析のダンプでは、部品は NULL かどうかを確かめたうえで、配列の外にあった NULL でない無効な値を読んで止まった[3]。また、規則のファイルは「コードでもカーネルの部品でもない設定」と CrowdStrike は書くが[2]、カーネルの中の部品が何を読むかを決めていた。振る舞いを変える設定は、コードと同じに扱う。

どこで止められたか

図3 段ごとの止める所

止める所	この件で	CrowdStrike の手当て
数を1か所で決め、組み立てで照らす	定義のファイルの21と、センサーのコードの20が別々にあった[3]	型が渡す入力の数を組み立ての時に確かめる仕組みを、7月27日に入れた。他の型にも食い違いが無いことを確かめた[3]
欄ごとに具体の条件で試す	試験の規則は21番目が全部、何でも合う条件だった[3]	全部の型で、欄ごとに何でも合う条件でない試験を作り、これからの型にも求める[3]
実物の部品に食わせて確かめる	確かめの仕組みは定義に照らすだけで、実際の解釈の部品に入れて試す段が規則ごとには無かった[3]	新しい規則を毎回試す手順を足し、入力の欄より多くの欄を見る規則を拒む確かめを8月19日までに入れるとした[3]
使う時に境界を確かめる	解釈の部品に、入力の配列の境界の確かめが無かった[3]	7月25日に境界の確かめと、配列の大きさと規則の期待の一致の確かめを足し、7.11 以上へ戻して入れる。ファジングも済ませた[3]
輪を分けて少しずつ配る	規則は段階的に配るべきだった、と分析は所見に挙げた[3]	少数の先行の端末から始め、輪ごとに様子を見る時間を置き、問題があれば戻す。顧客が規則の届く時と先を選べるようにした[3]
届いた後に戻せる備え	Microsoft の復旧の道具は、起動の媒体か安全な起動から元のファイルを消す形で、BitLocker の回復の鍵が要る場合があった[5]	Microsoft は、更新の管理と中身の解釈を、戻せる利用者の空間へ移すよう勧めた[6]

1から3は、誤った規則を作らせない守り、4は誤った規則が届いても止まらない守り、5と6は止まる台数と時間を絞る守りになる。この件では4が無く、5も無かったので、1から3の抜けがそのまま全台に及んだ。

守り方

根本の直し方

振る舞いを変える設定と規則は、コードと同じ道で出す。試験、段階的な配信、取り下げの手段を、コードの更新と同じにそろえる。
入力の数や形のような約束は1か所で定義し、確かめの仕組みと実装の両方をそこから作る。2か所に書けば、いつか食い違う。
外から来た設定を使う部品は、読み込む時に拒み、使う時にも境界を確かめる。確かめに外れた規則は捨てて、残りで動き続ける。
試験の入力は、全部の欄を実際に読ませる値にする。何でも合う条件や既定値ばかりの試験は、その欄の処理を通らない。
壊れると戻せない場所で動く部分を小さくする。Microsoft は、カーネルではデータの収集と強制だけにし、更新の管理や中身の解釈は利用者の空間で行うよう勧める[6]。

悪い例と直した例。架空の検知の部品が、配られた規則で入力の何番目を見るか

/* 通知ごとに用意する入力。数は1か所で決める */
#define NINPUTS 20
struct rule { unsigned field; const char *pattern; };

/* 悪い例 規則の番号をそのまま使う。field が 20 なら配列の外を読む */
const char *v = inputs[r->field];

/* 直した例 読み込む時に拒み、使う時にも確かめる */
int rule_load(const struct rule *r) {
    if (r->field >= NINPUTS) return -EINVAL;   /* この規則は捨て、残りで動く */
    return 0;
}
if (r->field >= NINPUTS) return NO_MATCH;
const char *v = inputs[r->field];

読み込みの確かめと、使う時の確かめは、どちらか一方では足りない。読み込みの確かめは定義が誤っていれば通り、この件の確かめの仕組みがそうだった[3]。
カーネルの中のメモリの誤りは、例外として捕まえられない。分析のダンプにも、例外の処理で守れない種類の停止と出ている[3]。だから、読む前に確かめる。失敗した時にどちらへ倒すかの設計は A10 例外的な状況への不適切な対応にある。

架空の規則の配信の段。先の輪で異常が出たら止めて戻す

rollout:
  rings:
    - name: internal        # 自社の端末
      share: 100%
      bake: 2h
    - name: canary          # 顧客の先行の端末
      share: 1%
      bake: 4h
    - name: broad
      share: 100%
  halt_if:                  # 前の版と比べて悪くなったら止める
    sensor_offline_rate: "+0.5%"
    crash_reports: "+0.1%"
  on_halt: rollback         # 止めたら前の版へ戻す

止める条件は、端末から報告が来なくなったことも数える。この件のように端末が止まると、誤りの報告そのものが届かない。

緩和の策

使う側は、製品の更新を届ける先を輪に分ける設定があれば使い、重要な端末を最初の輪に入れない。CrowdStrike は顧客が規則の届く時と先を選べるようにした[3]。
BitLocker などの回復の鍵を、止まった端末の外から引ける所に置き、引ける人を決めておく。この件の復旧の道具は、回復の鍵を求める場合があった[5]。
起動の媒体から直す、ネットワークから起動させる、作り直す、の手順を用意し、USB を挿せない端末と仮想の機械の道も決めておく[5]。
止める手段を、更新の仕組みと別の道に持つ。取り下げは、まだ受け取っていない端末を守るだけで、止まった端末には届かない。
試験が通ったことは、試験が十分なことを示さない。試験の入力が何を通っていないかを読む。読み方は AIの出力を確かめるにある。

参照

Technical Details: Falcon Content Update for Windows Hosts CrowdStrike、2024年7月20日
Falcon Content Update Preliminary Post Incident Report CrowdStrike、2024年7月24日、7月25日更新
External Technical Root Cause Analysis Channel File 291 CrowdStrike、2024年8月6日
Helping our customers through the CrowdStrike outage Microsoft、2024年7月20日
New recovery tool to help with CrowdStrike issue impacting Windows endpoints Microsoft、2024年7月20日、7月31日更新
Windows Security best practices for integrating and managing security tools Microsoft、2024年7月27日
Taking steps that drive resiliency and security for Windows customers Microsoft、2024年9月12日

CrowdStrike 2024年 配信した設定による Windows の一斉停止

要点

何が起きたか

起きた仕組み

どこで止められたか

守り方

参照

CrowdStrike 2024年配信した設定による Windows の一斉停止