CrowdStrikeが数か月前にDebian・Rocky Linuxも破損させていた件

 (neowin.net)
1 ポイント 投稿者 GN⁺ 2024-07-22 | 3件のコメント | WhatsAppで共有
  • Windowsでの大規模なBSOD障害とは別に、CrowdStrikeの更新がすでにDebianおよびRocky Linux環境でもサーバー停止を引き起こした事例があった
  • 4月、あるcivic tech labでは更新直後にすべてのDebian Linuxサーバーが同時にクラッシュして起動を拒否し、CrowdStrikeを削除して初めて復旧できた
  • 当該Debian構成はサポート対象と考えられていたが、最新の安定版Debianとは互換性がなく、根本原因分析でテストマトリクスの欠落が確認された
  • Rocky Linuxユーザーも、RockyLinux 9.4へのアップグレード後にCrowdStrikeを使用するサーバーがカーネルバグでクラッシュすると明らかにし、CrowdStrikeのサポートチームも問題を認めた
  • CrowdStrikeに依存する組織は、更新適用をより慎重に扱い、障害に備えた緊急時対応計画を持つ必要がある

Windows障害以前のLinux停止事例

  • Windows PCで発生した広範なBlue Screen of Death問題は、航空会社、銀行、医療提供者など多くの分野の運用を妨げた
    • 原因はCrowdStrikeが更新で配布した問題のある**チャネルファイル(channel file)**だった
    • CrowdStrikeは、このクラッシュはMacやLinux PCには影響しないと確認していた
  • しかし、DebianおよびRocky LinuxのユーザーもCrowdStrikeの更新による大きな中断を経験しており、これは更新とテスト手順への懸念につながっている
    • 日々CrowdStrike製品に依存する顧客にとって潜在的なリスクになり得る

DebianとRocky Linuxで確認された問題

  • Debianサーバーの同時クラッシュ

    • 4月、あるcivic tech labでCrowdStrikeの更新がすべてのDebian Linuxサーバーを同時にクラッシュさせ、起動不能にした
    • その更新は最新の安定版Debianと互換性がなかったが、そのLinux構成はサポート対象と考えられていた
    • ITチームは、CrowdStrikeを削除するとマシンが起動することを確認し、この事案を報告した

  • 対応遅延とテスト漏れ

    • 事案に関わったチームメンバーは、CrowdStrikeの対応の遅さに不満を示した
    • CrowdStrikeは問題を翌日に認めたが、根本原因分析の提供までには数週間かかった
    • 分析の結果、Debian Linux構成がCrowdStrikeのテストマトリクスに含まれていなかった
    • チームメンバーは「Crowdstrikeのモデルは、緊急かどうかやテストの有無にかかわらず、私たちが望むときに皆さんのマシンへソフトウェアをプッシュするというものに見える」と批判した

  • Rocky Linux 9.4アップグレード後のクラッシュ

    • Rocky Linuxユーザーは、RockyLinux 9.4へのアップグレード後にCrowdStrikeを使用するサーバーがカーネルバグでクラッシュすると明らかにした
    • CrowdStrikeのサポートチームはこの問題を認めた
    • 異なるオペレーティングシステムで互換性問題が繰り返され、テスト不足と注意不足のパターンが露呈した

組織が備えるべき点

  • 今後同様の問題を減らすには、CrowdStrikeはサポートされるすべての構成に対して、より厳格なテストを優先すべきだ
  • 組織はCrowdStrikeの更新を慎重に適用し、潜在的な中断を緩和するための緊急時対応計画を用意する必要がある
  • 関連ソース

関連記事

3件のコメント

 
click 2024-07-22

AIは本文ではなく広告を要約したようですね
 
xguru 2024-07-22

NeowinサイトはHTML構造がおかしく、上部バーのすべての広告が本文として認識されてしまうようです。修正しておきました。
 
GN⁺ 2024-07-22
Hacker Newsのコメント

  • OSS/Linuxエコシステムには、独立した緩やかに調整されたグループが無償でつなぎ合わせたコードの寄せ集めが多いにもかかわらず、数十億ドル規模の企業が作ったソフトウェアより堅牢なことが多いのは驚き
    理由の一つは、OSSのシステムプログラマーたちが汚れた洗濯物を公の場で洗うことかもしれない。「目玉が多ければバグは浅くなる」というより、「誰かに見られるだけで悪いコードは恥ずかしくなる」に近い
    ある商用プロジェクトをオープンソースとして公開しようとしているが、ソースコードを公開する前に、ドキュメント改善、TODO/FIXMEの整理、コメントの検証といった手入れをかなりしなければならない。とはいえ、クローズドな商用コードベースの内部ではそれよりはるかにひどいものも多く見てきたし、ほとんどのエンタープライズソフトウェアも同じような水準なのだろうと思う

    • OSSソフトウェアには利益動機がほとんどないため、何かを「売る」よりも「動くようにする」ために書かれる
      時間的なプレッシャーも少なく、リリースが遅れても四半期業績には影響しない。商用ソフトウェアはエンジニアリング作業というよりマーケティング作業に近いと思う
    • Linusなら同意しないだろうし、カーネルが常に巨大な壁を設けているのには理由がある。彼ならユーザー空間コードの大半を正当に拒むだろう
      カーネルの外にあるものが動くこと自体が奇跡であり、ディストリビューションのアップデートのたびにどれほど頻繁に壊れるか、再び動かすために全体をビルドし直さなければならないことがどれほど多いかを見れば分かる。本番環境でのアップデートは非常にストレスの大きい手順だ
      オーディオとビデオの話はまだ持ち出してもいないし、そこにWaylandまで乗ると別の悪夢になる。だから多くの面でWindowsのほうが標準に近いと思う。あらゆる方向から酷使されながらも、膨大な数のマシンで毎日重要な仕事をこなしているからだ
      金銭的な報酬を受けているかどうかは重要ではなく、Raymond Chenなどの文章に見られる意思決定の深さは、OSSの世界でも非常にまれだ
    • お金をもらって作っていても、MBAたちが最終判断を下す方式で作られたものは、趣味や情熱プロジェクトに比べてひどい場合が多い
      こうした状況は自分だけの話ではないと思うし、役に立つものや、自分たちがコントロールできる道具を作りたいから作るコミュニティが今後もあり続けてほしい
    • 締め切りも大きな要因である可能性が高い。多くのOSS開発者は余暇に自分や他人のためにプロジェクトを作っており、情熱プロジェクトなら自分の仕事により誇りを持てる
      商用ソフトウェアは、管理者の締め切りに合わせるためにダクトテープでつなぎ合わせたように感じることが多く、「まあいいか」となり、終わらせたことだけで満足してしまう
    • コードを書く人たちをアマチュアと呼ぶのは良い表現ではないと思う。大半は経験豊富で高度に技術的な人たちだろうし、「緩やかに調整されている」というのは多くの企業にも当てはまる
      オープンソースでコードを書く人たちは、関心があってやっている場合が重要だ。何かを良く、きちんと動き、賢いものにしたいなら、単にお金をもらってやる場合や恥を避けようとしてやる場合より、成功する可能性は高くなる

  • 昨日のCrowdStrikeの大規模スレッドにあった関連コメント：「CrowdStrikeは4月19日にわれわれの本番Linuxフリートでこれをやらかし、その間ずっと不満をぶちまけたくて仕方なかった」[1]
    その後、複数段落にわたる不満が続く
    [1] https://news.ycombinator.com/item?id=41005936

    • 数週間後に出た根本原因分析にも、われわれが使っていたシナリオはテストマトリクスに入っていなかった。Debian stableでn-1バージョンを実行するサポート対象構成に見えたにもかかわらずだ
      彼ら自身の事後分析でも、同じことが再び起きるのを防ぐ実質的な方法はなかった。「緊急かどうかに関係なく、テストもなしに、好きなときにあなたのマシンへソフトウェアを押し込む」という構造だったからだ
    • 単なる関連コメントではなく、このHNスレッドが記事で主要な情報源として使われたように見える

  • この分野で働いていたとき、常に「こういうものは実際に役に立っているのか？」という疑問がつきまとっていた
    答えるのが難しい質問だが、CrowdStrikeのような製品の効果を検証した第三者研究があるのか気になる。あるいは、皆がセキュリティ劇場のせいで生活をより悪くしているだけなのかもしれない

    • ワクチンの効果を研究しようとするのと似ている。それでも、すでに答えを言っているようなものだ。経営陣が消化できる測定指標を作り出せさえすれば、価値があると見なされる
      それほど侵襲的なものを追加することがどうして筋が通るのかは疑問だ。90年代には、アンチウイルス企業がウイルスを作ることもあり、自分たちが作ったものをネットワークに広めながら、購読者には魔法のように感染を防いでいた
    • 実際に何かを防いだのを見たことがあるのか気になる。そのツールを作った会社も当然、自社製品を使っていたはずなのに
      世界中のウェブに「見た人はいる？」と尋ねれば誰かは現れるだろうが、こうしたツールのせいでセキュリティ脆弱性を経験した人は非常に多く、安定性や可用性の問題を経験した人は、事実上そのツールを使っている人数と同じくらいだ

  • 製品品質は航空機からソフトウェアまで自由落下中。最近は誰もが追加収益ばかり気にしていて、QA不足がデフォルトになっている

    • 私たちの経済は利益に最適化されるようミニマックス化されてきて、いまその収穫期に入ったように思える
      ウクライナに送る砲弾を十分に作れず、チップ製造を国内に戻せず、船を建造できない理由も同じ
    • 技術者ではない人たちが意思決定をし、さらには技術プログラムを開発することまで増えたのも原因
      15年前は、業界の人のほとんどが本当にそこにいたいと思っていて、例外は少数だった。いまでは他の職業と同じになり、大半の開発者は成果物にほとんど関心がなく、結局アウトプットもひどいものになる
      ここ数年、自分のクソコードを実際にテストしてみるシニア未満の開発者にはほとんど会っていない
    • 失敗したときの経済的代償が、得られる利益より小さい。それが変わるまでは何も変わらない
    • これは単なる製品品質の問題ではない
      マーケティング臭のするインフルエンサーたちが、自分たちが何をしているかも分からないまま、ベンダーが引き起こしたパラノイアをコンプライアンスのチェックボックスで覆い隠そうとする人々にゴミを売っている構造だ。彼らは脅威モデリングも知らず、OSがどう動作するかも知らない
      CIA三要素で見ると、可用性は完全に諦め、システムのあらゆる動きをどこかのクラウド企業に送ることで機密性も一部犠牲にし、ベンダーが保証すらしない完全性という偽の安心感を得ようとしている。適切に階層化されたセキュリティアーキテクチャの中で、この製品が実際に何かをしているという証拠はほとんど見たことがない
      これはセキュリティ提案の真逆だ。虚偽と無能の上に築かれた砂上の楼閣で、文字どおりマルウェアの定義に近い。制御できないデータを外部に持ち出し、リモートのコマンド＆コントロール機能でシステムを倒せ、ring 0で完全に任意のコードを実行する
      2023年3月にこの全体を重大なビジネスリスクとして指摘したが、上の人たちが押し通した。反対意見は録音してあるので、今度はそれを使って仕返しするつもりだ
      人々が買うなら、ゴミとして作られても構わないことになる。そして実際にゴミとして作られている
    • 悲しいことだ。会社によって差はあるし、個人的にはソフトウェアエンジニアリングで一番好きな部分だが、多くの大企業は機会が訪れるやいなやQAを切り捨てた

  • CrowdStrikeがバグのあるDLLをWindowsアプリケーションに注入し、アプリケーション自体に非がなくてもクラッシュし得たという報告もあった
    https://x.com/molecularmusing/status/1808756095860543916

    • それはまったく別の事案だ。注入されるDLLはデフォルトでオフのオプション機能で、管理者には配布前にフリートとの互換性を確認するよう明示的に警告されている
      適用可能なフックのレベルは4段階に分かれており、だんだん不安定になっていき、UIとドキュメントで繰り返し警告されている。たとえばXUMDは、実行中のプロセスにライブラリをロードして複数のユーザーモードAPIをフックすることで、センサーが情報を監視できるようにする
      一部のエンドポイントテレメトリはユーザーモードフックでしか収集できない。XUMDはプロセスがどのAPIを利用しているかの情報を提供し、この情報は観測された累積的な挙動に基づくセンサーの複数の予防メカニズムに使われる
      AUMDとは異なり、クラウドはセンサー更新なしにXUMDの可視性を動的に変更できる。設定にはDisabled、Cautious、Moderate、Aggressive、Extra Aggressiveがあり、後ろに行くほど性能やアプリケーション互換性の問題が大きくなるため、本番環境には推奨されない
      XUMDはもともと一緒に開発されたわけではないユーザープロセスにロードされるため、特に他のセキュリティ製品がインストールされた環境では、クラッシュや起動失敗、性能低下が起きる可能性がある。どのプロセスがXUMD DLLをロードしたかを見るには、コマンドラインで tasklist /m csxumd* を実行すればよい

  • これらすべては、企業が結果的損害責任を契約で回避できるために起きている
    生命の喪失に対する結果的責任を契約で排除できないように、こうした条項も執行不能にするか、少なくとも制限すべきだ

    • それが欧州のサイバーセキュリティ指令がやろうとしていたことではなかったか？ 皆が怒って、FOSS例外ができたあの指令のことだ

  • 「アップデートはDebianの最新stable版と互換性がなかったが、そのLinux構成はサポート対象とされていた」と「分析の結果、Debian Linux構成はテストマトリクスになかった」という内容は、実際の詐欺にかなり近く見える
    構成Xをサポートすると宣言しておきながら、実際には構成Xをまったくテストしていないということだ。車にシートベルトがあると言いながら、製造工程のどこでもシートベルトが取り付けられ動作するか確認しないのと同じ
    自動車会社がそんなことをしたら起訴されていた気がするが、なぜCrowdStrikeはそうでないのか分からない。あるLinuxバージョンをサポートしないのは理解できるが、サポートすると宣伝しておきながらテストすらしていないなら、少なくとも故意の過失であり、もしかすると露骨な詐欺だ

  • 「誰も気づかなかった」という言い方は、CrowdStrikeがメディアに気づかれないよう押さえ込んだというかわいらしい表現のように聞こえる。バグが出た当日のHNの投稿には、人々が数か月前から問題を報告しようとしていたというコメントがあった
    記事でさえ、人々が問題に気づいていたように書いている。では誰が気づかなかったというのか？ それとも、その問題は無視されないほど有名ではなかったということか？

    • CrowdStrikeが報道を抑え込んだと見ているのか？ NY Times、WaPo、主要放送局に小切手でも送ったと思っているのか気になる
      メディアは航空機の運航停止のように現実世界で目立たない限り、サーバーが数台死ぬことには関心がない
    • 当時何かを見た記憶はあるが、Linuxにそういうソフトウェアを入れる人はごく少ないだろうと思っていた。実際にもそういう会社は非常に少ない
      爆発半径は小さく、おそらく出来の悪いNvidiaドライバよりも小さかったはずだ

  • ここにCrowdStrikeを使っている人がいるなら、これが正確に何をしているのか気になる。「アンチウイルス」と呼ばれているのを見るが、業務用ノートPCに入っているのを見ると、キーロガー兼アクティビティモニターのように見える
    「隠すものはない」とは言うものの、会社のスーパーユーザーたちに監視されるのはやはり気に障る

    • セキュリティ、コンプライアンス、法務チームからの承認印を取り付けられる
    • アンチウイルス/EDRソリューションをマルウェアやスパイウェアと呼ぶより、もっと良い解決策がある。業務用デバイスを私用に使わなければいい
      そのデバイスは会社の所有物であり、会社環境にアクセスするために使われるので、本物のマルウェアが入り込めば被害をもたらし得る責任のある接点だ。プライバシーが必要なら、別のデバイスを使うのが適切だ

  • ある会社ではすべてのエンドポイントにCrowdStrikeが配布されているというが、リソースを制限した仮想マシン内だけで実行しても、何も言われずに済んだ人もいるという。その時期ごろに仮想マシンが失敗するのも見たという
    別の大企業の元同僚からは、IT部門がLinuxエンドポイントのコンプライアンス強制をそのまま諦めたという話も聞いた。一部のIT管理者は実質的に「聞かない、言わない」方針を取っているようだ
    代替スタックを自分でうまく構成し、騒ぎを起こしたり嘘をついたりしないなら、好きにやれという感じだ。強制の動機の大半がチェックボックス式コンプライアンスなら、十分に筋が通る
    こうした一種の悪意あるコンプライアンスがどれほど広く行われていて、4月の事件がより大きなニュースにならなかったことにどれほど寄与したのか気になる