CrowdStrike 障害：Microsoft の計画は安全なカーネル・アクセスの推進にあるのか？

Microsoft’s Take on Kernel Access and Safe Deployment Following CrowdStrike Incident

2024/10/10 SecurityWeek — 2024年7月に CrowdStrike が原因となり発生した、大規模な Windows BSOD 障害の影響が落ち着きを見せる中で、再発を防ぐ方策の在り方が、いまの論点となっている。Microsoft Virus Initiative (MVI) サミットが開催され、CrowdStrike も含まれるメンバーたちが集まり協議したが、この問題に単純な解決策はない。SecurityWeek は、Microsoft の VP enterprise／OS security である David Weston にインタビューを行い、Microsoft の現在の考え方と計画について聞き出した。

CrowdStrike のインシデント

ことの発端は、2024年2月の時点で CrowdStrike が導入した、Falcon センサー 7.1 の新たな InterProcess Communication (IPC) Template Type にあり、そこでは 21件の入力フィールドが定義されていた。 CrowdStrike のヴィルス対応メカニズムでは、Channel Files 経由で配信されたコンテンツが使用される。そして、Channel Files 291 のコンテンツ・インタープリターが照合する入力値は、20件のみである。

続いて 2024年7月19日には、２つの追加の IPC Template Instances が展開された。これにより、20件の値のみが想定されているのに対して、21番目の値との比較が必要となった。CrowdStrike の言葉を借りれば、「21番目の値へのアクセスを試みたところ、入力データ配列の終わりを超えた範囲外のメモリ読み取りが発生し、システム・クラッシュにつながった」となる。

技術的な観点から見ると、BSOD が発生したエンドポイント端末と同様に、Microsoft も被害者である。Microsoft は直接的に関与はしていないが、CrowdStrike のカーネル・ドライバーが受けていた署名は、Microsoft Windows Hardware Quality Labs (WHQL) に評価されたものだ。クラッシュの原因は、ドライバー自体ではなく、カーネルの外側からドライバーに渡されたコンテンツであった。

Microsoft の David Weston は、「この問題は、当社では確認できないものであり、Microsoft のチェックをすり抜けていった。文書化されていないファイルの内容を、我々は把握していない。つまり、CrowdStrike だけが解釈方法を知っている、バイナリコードなのだ」と説明している。

MVI サミット

Microsoft にとって、このインシデントを防ぐ手立ては無かったが、今後に同様のインシデントを繰り返さないことを、同社は切望している。Microsoft は、 過去から学んで将来に生かしていく事柄を話し合うために、2024年9月10日に MVI サミットを開催した。  そこで議題になったのは、Windows カーネルへのアクセスと、展開前のソフトウェア・テストの２点である。

kernel の問題点

サードパーティのセキュリティ・プロバイダーにとって、カーネル内にドライバーを持つことの利点は明白である。それにより、自分たち (ひいてはユーザー) のセキュリティが向上し、パフォーマンスも改善される。しかし、その一方で、カーネルの障害による被害は広範囲に及び、復旧も容易ではないという欠点が生じる。

David Weston は、「カーネル・モードとユーザー・モードにおける問題の深刻さの違いは、カーネル・クラッシュの場合には、マシン全体がダウンしてしまう点にある。ユーザー・モードでアプリケーションがクラッシュしても、多くの場合おいて復旧は可能だ」と述べている。

それは、ユーザー・モードを最大限に活用し、カーネル・モードの使用を最小限に抑えるべきだという主張である。さらに David Weston は、「Microsoft Windows ユーザーにとって有益であるが、サードパーティのソフトウェアベンダーの一部も、ユーザー・モード・コンポーネントを採用する機会を歓迎するだろう。いま、Microsoft は、そのための機能に投資している」と述べている。

ただし、いくつかの懸念も寄せられている。Microsoft  はユーザー・モードをオプションとして増やすつもりなのか？ それともサードパーティのカーネル・ドライバーを段階的に廃止するつもりなのか？ MVI サミットの出席者である ESET は、「カーネル・アクセスがサイバー・セキュリティ製品で使用できるオプションとして残ることは、依然として不可欠である」とコメントしている。

その一方で Weston は、「カーネルから締め出されるのではないかという、一部のベンダーの懸念を受け止めている。ユーザー・モード・フレームワークは、パフォーマンスなどの面で、現時点で利用しているものと同等のものになるのかという、もっともな懸念だと理解している。しかし、現時点では、カーネル・アクセスを奪うという計画はない。将来的に変更する可能性がないわけではないが、現時点では、その計画はない。我々の目標は、ユーザー・モードに同等の選択肢を作ることだ」とコメントしている。

カーネルなのか？ カーネルではないのか？ ・・・という問題が注目されるのかもしれない。しかし Weston は、より重要なことは、展開前のソフトウェアのテストや、SDP (Safe Deployment Practices) の使用であると考えているようだ。

安全な展開の実践

Weston は、「セキュリティ製品がカーネル内で動作するのか、あるいは、アプリケーションとして動作するのかに関わらず、マシンが破壊されることもあれば、利用不可能になることもある。アプリケーションとして動作している場合であっても、誤ったファイルの削除により、マシンが起動しなくなる可能性がある。この事実だけでも、インシデントの保護という観点では、効果的な SDP の方が ROI が高いという主張が証明される。カーネル内であろうとユーザー・モードであろうと、誤ってシステムを停止させることを回避するには、SDP が必要だからだ」と述べている。

SDP は、新しい概念ではない。2004年には USENIX が、ユトレヒト大学による “A Safe and Policy-Free System for Software Deployment” という論文を発表している。その冒頭には、「ソフトウェア展開のための既存のシステムは、安全なものではなく、十分な柔軟性が確保されるものでもない」と書かれている。SDP の問題は、現時点で解決されているものではない。ただし、このようなソリューションが、将来においてカーネル・アクセスを制限するという、Microsoft  の計画の重要な側面になっていく。

この問題は、MVI サミットでも詳細まで議論されたという。Weston は、サミットに関するブログ記事で、「我々は、多様なエンドポイントに対して、どのように段階的な展開を行うかという決定から、必要に応じた一時停止やロールバックにいたるまで、共通の課題に直面している。それらを解決することで、Windows の広大なエコシステムにおける、アップデートの安全な展開が示現される。SDP の原則の中心は、ユーザーに送信されるアップデートを、段階的かつ徐々に展開することにある。サミットでの活発な議論が、MVI パートナーとの共同作業を継続し、今後はエコシステムとして活用していくための、共通のベストプラクティスを生み出すだろう」とコメントしている。

さらに、彼は、「パートナーが使用している様々な SDP アプローチを調整し、SDP の原則に関するコンセンサスとして、すべてのまとめる方法を話し合った。すべてを透明化したいが、それと同時に、Microsoft と協働するための要件として、この標準を強制したいと考えている」と SecurityWeek に対して述べている。

安全な展開のための最小セットについて、パートナーの同意を得ることは、１つの方法である。パートナーが合意した SDP の採用を保証することも、また１つの方法である。彼は「技術的な強制は難しいだろう。透明性と説明責任が、現時点では最善の方法論だと思われる」と指摘している。

Microsoft が、何の権限も持たないわけではない。たとえば、パートナーが SDP を無視していることが判明した場合には、カーネル・ドライバーへの署名を取り消すことが可能である。

David Weston は、「それは、現在のルート証明機関と協力している方法と同じだ。標準があり、そのセキュリティ標準に従わない場合には、そのパートナーは排除される。それにより、対象となるパートナーのビジネスに大きな影響が生じるだろう。それと同時に、透明性を重視することで、対象となるパートナーがユーザーに対して不誠実であるなら、その事実が明らかにされる。このようなレベルの強制は、かなり効果的だと考えている」と述べている。

Weston は、「私の TLDR (To-the-Point-Dear) は、SDP は停止を阻止するためのツールボックスの中で、最も優れたツールだということだ。カーネル・モードやユーザー・モードが無効だと言っているわけではなく、それらは問題のごく一部に過ぎないと言っているだけだ。SDP はカーネル内外の停止を阻止するのに役立つ」と、SecurityWeek に対してコメントしている。

Wndows における、セキュアなカーネル・アクセスはあり得るのかという議論が起こっています。しかし、エンドポイント・セキュリティを提供する企業は、それぞれの立場から反発するという展開が予想されます。この記事は、何らかのソースをもとに書かれたものではなく、いまの状況を整理するオリジナルの記事のようです。有り難いですね。よろしければ、以下のリストも、ご参照ください。

2024/09/24：CrowdStrike への米下院の公聴会：何が起こったのか？
2024/09/13：Windows カーネル連携方法の再設計を Microsoft が発表
2024/09/09：セキュリティ・ツール導入：CS の失敗から得るものは？
2024/08/30：CrowdStrike：９月の米下院の委員会で幹部が証言
2024/08/27：Microsoft がサミットを開催：エンドポイント企業が参加