すべてを壊したCrowdStrikeのファイル、null文字で埋め尽くされていた？

[GN⁺]

Hacker Newsの意見

• これほどクリティカルパス上にあるシステムなら、まともなCIパイプラインを通っていないはずがない
  自動テストにはそこまで厳格な方ではないが、こういう重要度のシステムでは状態管理が例外的にしっかりしているべきだ
  サポートを謳うすべての環境に対する統合テストなしに本番デプロイしてはいけないし、この規模と重要性の会社がサポート対象イメージ全体を検証するステージングや開発用テストサーバーすら持っていないというのは考えにくい

  • 情報が足りないのに仮定が多すぎる。たとえば実際には正常なファイルがあり、失敗箇所が検証済み成果物をCDNにアップロードするコードだった可能性もある
    そうなら、デプロイ前に多くのチェックを通過したあとで問題が起きたことになる。Windowsへの出力をまったくテストしていないと早急に断定したくはない
  • そんな環境がないと誰が言ったのか？ そうしたテストを全部通過していないと誰が言ったのか？ 今は仮定が多すぎる
  • 数年前、カーネル上で動く言語を担当するチームと面接したとき、CIで2万〜4万のマシン/OSの組み合わせと設定を回していると言っていたのを覚えている
    その中には当然、標準的なWindowsも入っていたはずだ
  • 受け入れ基準が「不正なデータ署名があればマシンの起動を止める」だったなら、破損した配布物やネットワーク障害を意味する可能性があるので、起動しないのは結果論では正しい挙動だったのかもしれない
    有効な署名付きファイルがダウンロードされるまで、マシンが完全には起動しない設計だった可能性もある
  • 全面がヌル文字で埋まったファイルが自動ビルドパイプラインの成果物だったとは考えにくい
    何かがビルドされてCIテストを通過したあと、配布準備のためにファイルをコピーする後段の工程でシステムが壊れた可能性に賭ける。ただ、今のところは全部推測にすぎない

• 関連して言うと、史上最大級の技術的惨事のうち二つ（CrowdStrikeと数年前のSolarWindsハッキング）がどちらも暴走したセキュリティソフトウェアから生じたのは偶然には思えない
  セキュリティソフトウェア会社を始めたがるハッカー気質の人たちは、プロセス重視の文化の退屈な部分を実装することには最も関心が薄いのではないかと思う。SolarWindsでは社内のセキュリティ文化がひどかったことが明らかになったし、今回も根本原因が判明すれば、速くて緩いデプロイプロセスだった可能性が高そうだ

  • 同意しない。セキュリティ企業は「大きすぎて潰れない」症候群に陥り、顧客はチェックボックスを埋めたがるので金が簡単に入ってくる
    セキュリティは購入する製品ではなく文化であり、初日から積極的な努力と骨の折れる作業によって根付かせる必要がある。市場にはセキュリティを提供してくれる製品はなく、問題が起きたときに責任転嫁できる製品があるだけだ
  • CrowdStrikeはもともとカリフォルニア州アーバインで創業し、本社を置いていた会社だった
    初期のエンジニアリング組織の大半はリモート/在宅勤務かアーバイン勤務で、規模拡大に伴ってSunnyvaleのオフィスを追加し、その後正式な本社をテキサス州オースティンへ移した
    ここ数年は海外のエンジニアリング運営も拡大しており、これにはオフショアリングも含まれていた可能性がある
  • 別の仮説だが両立は可能だ。セキュリティソフトウェアにはたいてい広範で強力なアクセス権限が必要だ
    そのため、ミスや侵害が起きると影響がはるかに大きくなりやすい
  • 業界の前歴としてはかなり独特ではある。ぱっと思いつくだけでもCrowdStrike、SolarWinds、Kaspersky、https://en.wikipedia.org/wiki/John_McAfeeがある
    まだ何か忘れていそうだ。合法大麻産業を悩ませる自己選択問題と似た構造なのかもしれない
  • セキュリティソフトウェアにはカーネルレベルのアクセスが必要だ。何か壊れると起動ループやクラッシュにつながる
    ほとんどの他のソフトウェアはそんな低レベルのアクセスを必要とせず、クラッシュしてもシステム全体を巻き込まず、高速な自動アップグレードも可能だ

• この災害の数少ない前向きな面を無理に探すなら、組織がカーネルレベルのアクセスを見直すのではないかというごく小さな希望がある
  どんなゲーム会社でもカーネルレベルのアンチチートソフトウェアを使うだけの力量があるとは言えない

  • Microsoftが非常に強く取り締まらない限り、ゲームソフトウェアが影響を受けることはなさそうだ
    それでもMicrosoft傘下にゲーム会社があるので、ゲーム向けフックは今後も減っていく可能性が高い。企業組織はRiotのアンチチート慣行に眉一つ動かさないだろうが、それは業務用マシンにLoLをインストールしないからだ
  • 戦うべき相手は「無作為なカーネルレベルのドライバー？ 問題なし！」と言うチート購入者たちだ
  • アンチチートは大半がサーバー側の行動ベースであるべきだと思う
  • macOSでは少なくともカーネルアクセスは不可能だと理解しているので、その点だけは救いだ

• これは、QA担当者が空ファイルと最小限の有効ファイルの次に、2番目か3番目に試しそうなテストファイルに見える。ここで露呈した全方位的な無能さの度合いには衝撃を受ける
  非技術系の役員にプレゼンで感銘を与えることが重視される競争市場では、技術的に有能な会社が無能な会社より優位に立てないのも不思議ではない
  最近、Craig Wrightの判決文 https://www.judiciary.uk/judgments/copa-v-wright/ を読んだが、サトシ・ナカモトだと虚偽の主張をしていた彼は、自分が世界的専門家だとしていた分野ですら基本的な技術力がなかった。証言台では unsigned が何を意味するのかも知らず、90年代から大企業のセキュリティ業務に携わりつつ、専門用語や細工されたデモ、偽造文書で人々をだましてきたように見えた
  CrowdStrikeの創業者兼CEOであるGeorge Kurtzは、14年前にMcAfeeがほぼ同じことをしたときCTOだった: https://old.reddit.com/r/sysadmin/comments/1e78l0g/can_crowd... https://en.wikipedia.org/wiki/George_Kurtz
  CrowdStrike自体も3か月前、Debian stableで同じ問題を起こしていた: https://old.reddit.com/r/debian/comments/1c8db7l/linuximage6...
  PCIコンプライアンスの規定が、CrowdStrikeやアンチウイルスを今日のITインフラのほぼ至る所に押し込んだことは恐ろしい

  • コンプライアンスが巨大な単一障害点として最大の脆弱性を生み出したのも皮肉だ
    まあ、政府規制とはそういうものだが
  • 今回の事故の最悪な点は、国家主体が今や大規模インフラ攻撃の明確な設計図を手にしたことだ
  • リンク先の人たちがこれを「Microsoft障害」と呼ぶことに腹を立てて、「CrowdStrikeのせいだ」と言っているのは面白い
    だが、これはMicrosoftの失敗でもある。もっと大きく見れば、またしても業界全体の失敗だ
    私たちが70年も研究してきた、安全で信頼できるシステムを作れるようにする業界改革が起きるには、こういうことがあと何回繰り返されなければならないのか。1988年がまた繰り返されているように感じる
  • Craig Wrightが、デジタル証明書を一か所のコンピュータやクラスターに発行させるのではなく、ブロックチェーンに載せようと提案していたのはかなり皮肉だ
    一か所にあれば標的になるが、ピアツーピアネットワークは攻撃にはるかに強靭だ
    今回の問題が、すべてのコンピュータのルート証明書がCrowdStrikeに置き換えられていたことと関係していたなら、ブロックチェーンに登録された証明書が解決策になるかもしれない。暗号の専門家ではないが、もっともらしくは見える
    付け加えると、Craig Wrightのブロックチェーン説明を聞いて初めて、ビットコイン白書がかなり理解できるようになった。彼は最高のコーダーではないかもしれないが、数学者がセキュリティで役に立たないわけではないだろう？
  • 陰謀論めいて聞こえたくはないが、まだハンロンの剃刀だけで悪意を排除するには早すぎる気がする
    たいていのミスは、こんな世界規模のとんでもないものにはならない。これまでで最大のミス、つまり実際には起きなかったY2Kのように見える

• この記事は間違っているし、フロントページから下ろすほかの方法がないのでフラグを立てた
  壊れたコンピュータで全ゼロのファイルが見つかったからといって、そのファイルが最初から全ゼロで配布されたことを意味するわけではない
  https://x.com/craiu/status/1814339965347610863
  https://x.com/cyb3rops/status/1814329155833516492

  • CrowdStrikeは、ネットワークソケットで転送中のファイルがマルウェア署名と一致すると、そのファイルをゼロで置き換える動作をする
    これらのファイル自体がマルウェア署名ファイルだったのなら、一致が出ても驚きではない
  • CrowdStrikeがついに自ら確認した: https://www.crowdstrike.com/blog/tech-analysis-channel-file-...

• このバグについて、CrowdStrikeで働く人を知っている友人から聞いた話と一致する
  バグは何年もカーネルドライバの中に潜んでおり、不正なデータが入り込んだことで発火した。そのデータは設定アップデートの後処理段階で追加され、テスト後ではあるが、クライアントが取得するアップデートサーバーにコピーされる前のことだった
  CrowdStrikeのテスト構成は、設定データそのものについては問題なかったようだが、本番に出る前には検出できなかった。間違ったものをテストしていたからだ
  事後分析を出すのなら、この問題を認め、もう一つの世界規模の影響を及ぼすプロセス障害を防ぐために何をするのか説明してほしい

  • ようやくある程度筋の通る説明になった
    有能なシステム管理者なら、今ごろGreenlandからNew Zealandまで全員、自動更新機能を切り、ファイアウォールで遮断し、サーバー資産からこの製品をできるだけ早く外す計画を立てているだろう
    競合製品のマーケティング予算は今四半期に増えそうだ
  • CrowdStrikeは、単に「認める」だけでは済まないはずだ
    契約書に「責任制限」があったとしても、真剣な調査と罰金、法的追及が行われてほしい
    この事故が生んだ被害の規模は計算するのも難しく、企業や一般人が浪費した時間まで含めればさらに大きい。たとえば航空便に乗ろうとしていた人たちも含まれる
    このような不注意には必ず代償があるべきだ

• MastodonでKevin Beaumontが受け取ったファイルは、顧客ごとに異なるという主張がある
  https://cyberplace.social/@GossiTheDog/112812454405913406
  少し下へスクロールすれば見られる

  • Windowsはすべてのカーネルモジュール署名を要求するものだと思っていた
    単なるテスト流出ではなく、破損したコピーが複数あるのなら、どうやって署名検証を通ってカーネルがロードできたのか疑問だ

• これは元のファイル内容ではなく、被害を止めようとする手動対応の結果だった可能性もある
  誰かが誤ったファイルを同じサイズの全ゼロのファイルで上書きすれば、アップデートが無害になると期待したのかもしれない
  あるいは「重大な脆弱性のためにQAを迂回した」という仮説に従うなら、実際のパッチ配布を止めたのは、本物のデータへのアクセスを減らし、脆弱性のリバースエンジニアリングを遅らせようとする試みだった可能性もある

• 4chanの技術掲示板に投稿された説明によれば、問題は2段階だった
  CSAgent.sysという署名済みカーネルドライバがCrowdStrikeのウイルス定義ファイルをパースし、malformedな定義ファイルが不正なメモリアクセスを引き起こす場合を適切に処理していなかった
  正常な定義ファイルとともに何カ月も問題なく動いていた時限爆弾カーネルドライバがあり、ある時点で定義ファイルを配信するWebサーバーやCDNが、空ファイル、任意のバイト列、別のソフトウェアのファイルといった誤った内容を返し始めた
  更新クライアントがこれを C:\Windows\System32\drivers 配下にダウンロードし、CSAgent.sysがそれを再び読み込んでパースしようとして PAGE_FAULT_IN_NONPAGED_AREA でブルースクリーンと再起動ループに陥った、という説明だ
  CSAgent.sys_18511.sysとCSAgent.sys_18513.sysの差分を見ると、サイズチェックとバッファサイズを変更し、今後は不正な定義ファイルがクラッシュを引き起こさないようにした痕跡が見られるという

  • 定義ファイルを配信するサーバー上で、何らかのウイルス保護機能がディスク読み取りを妨げ、エラーを返す代わりに出力データを0で埋めたようにも聞こえる
    実際に何らかのアンチウイルスパッケージが原因だったなら、かなり皮肉だ
  • こうしたことが複数回起きていたのなら、ずさんに書かれたカーネルドライバを狙ったハッカー攻撃だった可能性もある
    特に今のような選挙の時期や、Trumpが好む企業という文脈では、力の誇示だったのかもしれない

• 以前にもセキュリティソフトがファイル全体を0に置き換えて、ソフトウェアのコンパイルを壊したことがあった
  今回がそうだと言っているわけではないが、それでも驚きではない
  基本的にはWindowsでリンカーがファイルを開けなかったのだが、別プロセスがスキャンのためにロックしていたからだ。ところがエラーを返さず、リンクされるはずのオブジェクトコードを0に置き換えてしまった
  人々は原因を突き止められず、デバッガを開いて初めてオブジェクトコードの大きな塊が0に置換されているのを確認した

  • Visual Studioがたった今コンパイルしたファイルに書き込めない問題には、あまりにも何度も遭遇している
    アンチウイルスが新しく生成されたバイナリを、ちょうどmt.exeが書き込むべきその瞬間に捕まえてしまうので、リトライを追加したmt.exeラッパーまで作ってある。CIビルドもこのせいでランダムに失敗することがある