https://error-daizenn.hatenablog.com/entry/2025/10/18/140317

2025年10月17日公開

「Rustで書かれたWindowsカーネルがブルースクリーン（BSOD）を引き起こす脆弱性を含んでいた」――セキュリティ研究者Check Pointが発見したこの事実は、Microsoftが推進してきた“Rustによる安全なOSカーネル化”に大きな波紋を投げかけました。

問題が見つかったのは、Windows 11 24H2ビルドで導入されたRust製GDI（Graphics Device Interface）コンポーネント。この新しいグラフィックドライバは、従来のC/C++コードを置き換える形で再設計されたものですが、研究チームのファジング（fuzzing）テストによってシステム全体が強制クラッシュし、ブルースクリーンが発生することが確認されました。

Microsoftはこの問題を「中程度（Moderate）」と分類しましたが、企業環境で悪用されれば、業務停止を引き起こすDoS（Denial of Service：サービス拒否）攻撃として十分に脅威になり得ます。

どんな脆弱性なのか：GDI（Graphics Device Interface）の新実装に潜む欠陥

GDIは、Windowsが2Dグラフィックスを描画するための基盤技術です。
今回の脆弱性は、Rust言語で再構築されたwin32kbase_rs.sysというドライバ内で発生していました。

具体的には、図形描画時の「パスからリージョン（領域）への変換処理」において、**配列アクセス範囲外（out-of-bounds access）が発生。Rustの安全機構がこれを検知してpanic_bounds_check()**を呼び出し、結果的に「SYSTEM_SERVICE_EXCEPTION」エラーを発生させてシステムを停止させます。

つまり、Rustの「安全装置」が働いた結果としてブルースクリーンになったという、皮肉な構図なのです。

研究者が発見した経緯：Check Pointによる“ファジング攻撃テスト”が契機

Check Pointの研究チームは、Windowsのグラフィックサブシステムを対象にした**ファジングキャンペーン（fuzzing campaign）**を実施していました。
この手法は、プログラムに大量の“異常な入力データ”を送りつけ、挙動の異常やクラッシュを検出するというものです。

テストには「WinAFL」や「WinAFL Pet」などのツールが使われ、EMF（Enhanced Metafile Format）およびEMF+ファイルに焦点を当てていました。
これらのファイル形式は、画像・文書内に埋め込まれる複雑な構造を持ち、GDIが処理を誤るとシステム全体に影響することがあります。

最初はわずか16個のサンプルデータから始めたにもかかわらず、テストの過程で数百回のクラッシュが発生。
最終的に、836個のクラッシュサンプルの中から1つのカーネルレベル異常が特定され、ブルースクリーン（BSOD）を引き起こす原因が突き止められました。

発生箇所：win32kbase_rs.sysでRustのpanic_bounds_checkが作動

問題のコードは、NtGdiSelectClipPath関数内の「region_from_path_mut()」呼び出しに存在しました。
この関数は、描画パスをリージョンに変換する処理を行うもので、内部で**単方向リスト（singly linked list）**による境界線（edge）処理を行っています。

チェックポイントの分析によると、境界線リストの管理が不完全で、配列境界を超えてアクセスしてしまうケースが存在。
Rustランタイムはこれを「panic」として検知し、例外を発生させてシステムを強制停止しました。

結果、Windowsカーネルは「SYSTEM_SERVICE_EXCEPTION（サービス例外）」として処理し、ブルースクリーン状態に移行。
従来のC言語なら“静かに破損”するところを、Rustでは安全機構がクラッシュを引き起こしてくれる、という形になっています。

不正なEMF+ファイルでクラッシュ、BSOD（ブルースクリーン）発生

脆弱性を再現した決定的なトリガーは、EmfPlusDrawBeziersレコードというGDI描画命令を含むEMF+ファイルでした。
ファイル内では「17点ある」と宣言されているにもかかわらず、実際には「4点分のデータ」しか存在しないという不整合がありました。

さらに、EmfPlusObjectで定義された極端に太いペン（wide stroke pen）が描画処理を複雑化。
この結果、リージョン変換中に境界リストが破綻し、Rustのバウンドチェックが作動してpanic、そのままブルースクリーンへとつながったのです。

Check Pointは、この現象を「Denial of Fuzzing」と呼びました。
なぜなら、システムがクラッシュするたびにファジングテストそのものが止まってしまい、分析が中断されたからです。

PoC（概念実証）コードで確認：PowerShellでも再現可能

Check Pointは、研究の一環としてPowerShellによる簡易PoC（Proof of Concept）コードを作成しました。
このコードでは、System.Drawing名前空間を使って細工済みのEMF+ファイルをGraphicsオブジェクトに読み込むだけでブルースクリーンが発生します。

驚くべきことに、標準ユーザー権限でも実行が可能。
つまり、管理者権限を持たない一般ユーザーが実行しただけで、システム全体をクラッシュさせることができるのです。

このことから、Microsoftは「リモートコード実行ではないが、DoS攻撃としては十分危険」と分類しました。
研究者たちはこのPoCを使い、再起動までの平均時間を30分からわずか数分に短縮し、合計38万回目のテストで完全再現に成功したと報告しています。

Microsoftによる修正：KB5058499（2025年5月28日プレビュー）で対応済み

この問題はCheck Pointが2025年1月に報告し、Microsoftは2025年5月28日に公開したプレビュー更新KB5058499（OS Build 26100.4202）で対処を始めました。。Check PointのレポートとMicrosoftの更新履歴を照合すると、同更新で該当するGDIの処理ロジックに境界チェックを強化する修正が加えられたことが確認できます。Check Point Research+1

修正版の要旨は、従来の境界処理（add_edge_original）に加えて、厳格な境界チェックを行う新処理（add_edge_new）を導入し、問題のトリガーとなったケースを排除することです。Microsoftはまずプレビューで配布し、6月にかけて段階的に本配信を行いました。なお初期のロールアウトでは機能フラグが切られている環境もあり、すべての端末で即時に完全保護が行われたわけではありません。Check Point Research+1

修正後の現状と「中程度（Moderate）」評価の意味合い

MicrosoftはこのDoS（ブルースクリーン誘発）問題を“中程度”として扱いました。理由としては、今回のバグはリモートで任意コード実行（RCE）を直接引き起こすものではなく、主にサービス拒否（DoS）に近い影響だったためとされています。しかしCheck Pointや複数のセキュリティ系報道は、企業規模での悪用が簡単に業務停止を招き得る点を強調しており、評価は必ずしも軽視できません。実際、ファジングで短時間に再現可能なPoCがあるため、内部からの悪用や自動化攻撃で広範囲に被害が出る懸念は残ります。Check Point Research+1

なぜ「Rust採用」でこうした問題が起きたのか — 言語の限界と設計上の落とし穴

多くのメディアは「Rustを使えばバッファオーバーフローは減る」と報じてきましたが、今回の件は“言語そのものの安全性”と“アルゴリズム／実装設計の正しさ”は別物であることを示しています。 Rustは確かに低レベルなメモリ破壊を防ぐ堅牢な機能を持ちますが、設計上の不整合（たとえば入力フォーマットの不整合やリスト管理の不備）を防ぐわけではありません。Check Pointはまさに、EMF+の“宣言されている点数と実データの不一致”といった論理的な不整合が根本原因だと報告しています。Check Point Research

さらに今回はRustの境界チェック（panic）がOS全体の安全動作として“クラッシュ”を選ぶ設計になっている点が議論の的になりました。すなわち、Rustが「安全のためにpanicする」ことでシステムを止めてしまい、それがサービス停止（DoS）につながった面もあるわけです。言語を採用したからといってテストや設計の重要性が減るわけではない、という当たり前の教訓が改めて示されました。Check Point Research

セキュリティ研究者の声：ファジング継続の重要性と“Denial of Fuzzing”の示唆

Check Pointの報告は、ファジングとカーネルフォレンジクスの連携がいかに重要かを示しました。**「Denial of Fuzzing（ファジングの妨害）」**と名付けられた現象は、テスト対象が繰り返しクラッシュすると解析が止まってしまう点を指します。対策としては、メモリダンプ収集やテストハーネスの分離、さらにクラッシュを検出した際の自動回復手順を入れる必要があり、単に入力を投げるだけのfuzzでは検出が不十分であることを示唆します。Check Pointはデバッグのためにカスタムのハーネスやリモートストリーミングを用いて解析時間を大幅に短縮しました。Check Point Research

エンタープライズにとってのリスク：内部悪用と運用停止のシナリオ

企業視点では、今回の脆弱性は「内部からの悪用」による影響が特に怖い点です。標準ユーザー権限からでもPoCを実行でき、結果としてマシンを即座に再起動／停止させられるため、攻撃者（あるいは不注意なスクリプト）が業務サーバやVDI群を止めることが可能です。RDPセッションや共有ドライブに置かれた細工ファイルがトリガーになれば、短時間で広域な混乱を招きます。報告では、攻撃のトリガーにEMF/EMF+ファイルが使われており、ドキュメントやメール添付経由での伝播を想定する必要があります。Check Point Research+1

管理者向け実務的な対処（チェックリスト）

KB5058499以降の更新が適用されているか確認する。（OS Build 26100.4202以降のパッチを確認）｡マイクロソフトサポート
ファイルスキャン（EMF/EMF+を含む）を強化し、受信メールや共有フォルダに細工ファイルがないかをチェックする。
ユーザーの権限最小化を徹底し、標準ユーザーでも危険なファイルを実行できない運用にする。
ログと再起動履歴を監視し、短時間に多数のクラッシュ／再起動があれば即時インシデント対応を開始する。
SIEMルールを追加して、GDI系エラーやSYSTEM_SERVICE_EXCEPTIONが頻発したらアラートを上げるようにする。

フォーラムや開発者コミュニティの反応：学びと皮肉が交差する場に

SNSや技術フォーラムでは「RustでもBSODが起きるのか」「言語を変えれば解決、というのは幻想だった」といった冷笑交じりの反応が散見されます。一方で多くの開発者は「重要なのは言語ではなく設計とテスト戦略だ」と冷静に整理しており、今回の発見は全員にとって貴重な学習材料と受け止められています。Check Pointの公開レポートは詳細で再現手順も示されているため、研究コミュニティでは今後の防御策検討に活用されるでしょう。Check Point Research+1

結論：Rust採用は前進だが、「言語＝完全解」ではない

**Rustの導入はメモリ安全性の向上という点で正しい一手です。**しかし今回のように、入出力仕様の不整合やアルゴリズム欠陥は依然として致命傷になり得ます。言語が提供する安全装置は「最後の砦」であって、設計・レビュー・ファジング・フォレンジクスといった防衛層を省略してよい理由にはなりません。今回の教訓は明確です：言語に頼るだけでなく、設計とテストをより強固にすることが不可欠です。Check Point Research

もしあなたが企業管理者であれば、まずはKB5058499以降の更新確認とEMF/EMF+ファイルの取り扱いルールの見直しを行ってください。個人ユーザーであれば、Windows Updateを確認し、怪しい添付ファイルは開かないようにするだけで十分にリスクを下げられます。

この記事が役に立ったら、あなたの環境で確認した結果や、フォーラムで見つけた有効なワークアラウンドをコメントで教えてください。みんなで情報を出し合えば、より安全な運用方法が作れますよ。