- Windows GDI には、Windows および Windows Server の複数のバージョンに影響する情報漏洩、サービス拒否、リモート コード実行の脆弱性が蓄積されています。
- これらの脆弱性の多くは、EMF/WMF ファイルや、gdi32.dll および win32k.sys によって処理される不正なグラフィック コンテンツを通じて悪用され、BSOD やメモリ リークを引き起こす可能性があります。
- Microsoft は、gdi32.dll などのバイナリに対する変更を含む累積パッケージでパッチをリリースし、インストールが成功したことを確認するためのハッシュとファイル情報を提供します。
- 迅速なパッチ適用、ネットワークのセグメンテーション、危険なグラフィック形式の制限、EDR による監視の組み合わせが、GDI に関連するリスクを軽減する鍵となります。
Windowsのグラフィカルユーザーインターフェイス（GDI）は、ほとんどのユーザーが意識することなく、数十年にわたりウィンドウ、テキスト、アイコン、画像などをレンダリングしてきました。しかし、この基本的なシステムコンポーネントは、重大なセキュリティ脆弱性の原因にもなっており、ゼロデイ攻撃によるものもあれば、マイクロソフトの大規模なアップデートで修正されたものもあります。GDIに不具合が発生すると、単にアプリケーションがクラッシュするだけでなく、場合によってはデータ漏洩、リモートコード実行、あるいはサーバー全体をダウンさせるブルースクリーンエラー（BSOD）につながる可能性があります。
以下の説明では、GDI の仕組み、近年文書化された具体的な脆弱性 ( CVE-2017-11816、CVE-2020-1435、CVE-2023-36884 など)、それらの悪用方法、家庭や企業環境への実際の影響、そしてWindows Vista SP2のような古いバージョンから Windows 11 や Windows Server の最新バージョンまで、管理者やサイバーセキュリティ専門家が Windows システムを保護するために適用できる実際的な対策について詳しく説明します。
Windows GDI とは何ですか? セキュリティの面でなぜそれほど重要なのですか?
グラフィックスデバイスインターフェイス（GDI）は、線や四角形の描画から、画面やプリンタへのフォント、ビットマップ、画像の表示まで、グラフィックスレンダリングに関するあらゆることを管理する、従来のWindows APIです。アプリケーションは、gdi32.dllなどのライブラリの関数を呼び出して、デバイスコンテキスト（HDC）、ブラシ、ペン、領域、その他のグラフィックオブジェクトを作成します。これらのオブジェクトは、カーネルが制御するデータ構造によって内部的に管理されます。
GDIアーキテクチャは、ユーザーモードとカーネルモードに分かれています。ユーザーモードでは、gdi32.dllなどのDLLと関連ライブラリがアプリケーションから描画要求を受け取ります。これらの呼び出しは、win32k.sysを介してカーネルモードで動作するWindowsウィンドウサブシステムに渡されます。このカーネル部分が、実際にシステムメモリを操作し、グラフィックオブジェクトを検証し、ハードウェアに送信する役割を担います。この段階でポインタ、サイズ、インデックスの検証が不十分だと、致命的なエラーが発生する可能性があります。
システムはリソースを追跡および再利用するために、GDIオブジェクトテーブルを保持しています。各プロセスは独自のテーブルを持ちますが、共有オブジェクト用のグローバルテーブルも存在するため、バッファオーバーフロー、ダブルフリーイベント、または無効なメモリ参照が発生した場合に破損する可能性が高まります。これらの種類の障害は、カーネルメモリの破損、競合状態、システムクラッシュ、さらにはシステムの最も特権的なコンテキストでの任意のコード実行につながる可能性があります。
より新しいAPI（GDI+、Direct2D、DirectWrite、さらにはDirectComposition）の登場に伴い、マイクロソフトは新規アプリケーションにおけるGDIの使用を減らしてきましたが、依然としてGDIに依存しているレガシーソフトウェアのエコシステムは膨大です。このレガシーシステムの存在により、GDIは研究者や攻撃者にとって非常に魅力的な攻撃対象となっています。
歴史的脆弱性：情報漏洩からゼロデイまで
GDIに関連する最も古い脆弱性の1つに、情報漏洩の脆弱性であるCVE-2017-11816があります。この脆弱性は、GDIがメモリ内の特定のオブジェクトを処理する方法に問題があり、悪意のあるユーザーが本来アクセスできないはずのデータをターゲットシステムから取得できてしまうというものでした。これはコード実行ではなく、深刻な機密情報漏洩でした。
この脆弱性はWindowsの様々なエディションに影響を与え、マイクロソフトは専用のセキュリティアップデートをリリースせざるを得ませんでした。この欠陥はグラフィック構造の内部処理にあり、サブシステムが特定のメモリ領域を再利用する前に適切にクリアまたは検証していなかったため、他のプロセスやオペレーティングシステム自体に属する残留情報を読み取ることが可能になっていました。
この修正プログラムは、2017年10月の定期的な「パッチチューズデー」サイクルに含まれるセキュリティ更新プログラムで提供されました。脆弱性の説明とともに、マイクロソフトは影響を受けるファイルとその新しいバージョンを一覧にした詳細な表を提供しました。例えば、x86、x64、IA-64プラットフォーム向けのgdi32.dllの異なるビルドが、2017年9月8日などの日付と、6.0.6002.24200などのファイルバージョンとともに記載されていました。この詳細情報により、管理者はパッチが正しく適用されたことを確認することができました。
その後、Project Zero（Google）の研究者らは、ユーザーモードのgdi32.dllに関連する別のゼロデイ脆弱性を明らかにした。今回の脆弱性は、EMF（拡張メタファイル）レジスタに埋め込まれたDIB（デバイス非依存ビットマップ）の処理に影響を与えるものだった。メタファイル内のこれらのビットマップを不適切に操作することで、プロセスメモリから情報を抽出することが可能になり、データプライバシーに直接的な影響を及ぼす。
このゼロデイ脆弱性は、特別に細工されたEMFファイルを含むDOCXドキュメントを開くことで、ローカル環境ではInternet Explorer経由で、リモート環境ではOffice Online経由で再現可能でした。影響を受けるバージョンは広範囲にわたり、Windows Vista Service Pack 2からWindows 10まで、さらにWindows Server 2012 R2や2016などのバージョンも含まれていました。この問題は、標準的な90日間のProject Zero期間が経過してもパッチがリリースされなかったため公になり、この脆弱性が実用的なゼロデイ攻撃として正式に認められました。
一方、マイクロソフトは注目すべき事態に見舞われた。社内の問題により、予定されていたパッチチューズデーのパッチパッケージのリリースが1か月遅れ、修正プログラムの適用が次のサイクルまで延期されたのだ。こうした遅延は、研究コミュニティに既に知られている脆弱性が露呈する期間を長くすることになる。
最近の重大なバグ: BSOD、リモート実行、大規模なパッチバッチ
GDI の脆弱性は、時間の経過とともに、より深刻な事態へと発展してきました。特に顕著な例として、 CVE-2023-36884 として識別されるサービス拒否の脆弱性があり、これは Windows 10 (バージョン 1607 以降)、Windows 11、および Windows Server 2016、2019、2022 に影響します。この識別子は、セキュリティ情報によって異なるコンポーネントに関連付けられていますが、技術分析では、不正なグラフィック オブジェクトを処理する際にブルースクリーン (BSOD) を引き起こす可能性のある、グラフィック サブシステムの重大な欠陥について説明しています。
この問題は、win32k.sys の NtGdiDdDeleteDeviceBitmap 関数に関連しています。無効なグラフィック ビットマップまたはデバイスを処理する際に、脆弱なコードは、デバイス構造 (DD_DEVICE_OEM 型など) からデータをコピーする際に、バッファ境界の徹底的なチェックを実行しません。このチェックの不備により、カーネル内で隣接するメモリが上書きされ、メモリ アクセス例外 (PAGE_FAULT_IN_NONPAGED_AREA、コード 0x00000050) が発生し、IRQL_NOT_LESS_OR_EQUAL などのコードを含むブルースクリーン (BSOD) がトリガーされます。
典型的な攻撃フローは、SMBやRDPなどのネットワークプロトコルに埋め込まれたグラフィックデータ、あるいはWebDAVや印刷サービスを介してデータを取得することから始まります。不正なEMFファイルがリモートドキュメントやストリームの一部として転送され、Office、Edge、画像ビューア、あるいはファイルエクスプローラーなどのアプリケーションがその内容を解釈しようとすると、GDIサブシステムが呼び出されて処理されます。解析ルーチンは特定のオブジェクトレジスタの検証に失敗するため、範囲外のポインタが逆参照され、カーネルメモリ（特に非ページプール）が不安定になります。
公式速報で報告されている影響はサービス拒否（DoS）に焦点を当てていますが、さまざまな研究者は、メモリ破損を悪用するより高度な技術（たとえば、ヒープへの攻撃）を使用すると、MSHTMLなどの他のコンポーネントの脆弱性（CVE-2021-40444のケース）で見られたのと同様に、カーネルモードのコード実行につながる連鎖を構築できる可能性があると指摘しています。
GDIの重要性は、大規模なパッチのリリースにも反映されています。2020年7月、マイクロソフトは自社製品の123件の脆弱性を修正する大規模なアップデートをリリースしました。そのうち18件は重大な脆弱性として分類されていました。後者の中には、GDIがメモリ内のオブジェクトを操作する方法に直接関連するCVE-2020-1435が含まれていました。攻撃者が被害者を騙して特別に細工されたコンテンツを開くように仕向けた場合（例えば、悪意のあるWebサイトにアクセスさせるなど）、ユーザーと同じ権限でリモートコード実行をトリガーできる可能性がありました。
同じバッチには、特殊なフォントの処理に関連するCVE-2020-1436と、特に注目を集めたCVE-2020-1350が含まれていました。CVE-2020-1350は、ワームのような機能を持ち、ユーザーの操作なしにマルウェアを拡散できるWindows DNSサーバーの重大な脆弱性です。後者はGDIには影響しませんが、状況をよく示しています。単一のパッチパッケージに、ネットワークサービス、ハイパーバイザー（Hyper-Vにおける複数のリモート実行の欠陥）、そしてグラフィカルインターフェイス自体の脆弱性が含まれていたのです。
CVE-2020-1435は、具体的にはGDIがメモリ内のグラフィックオブジェクトを処理する方法に関連する脆弱性です。この脆弱性を悪用されると、攻撃者はプログラムのインストール、データの表示、変更、削除、および完全な権限を持つユーザーアカウントの作成が可能になります。典型的な攻撃手法は、ユーザーを悪意のあるWebサイトにアクセスさせたり、脆弱性を悪用するように設計されたグラフィックリソースを含むファイルを開かせたりすることです。これはGDIの過去のパターンと一致しており、システムが最新の状態でない場合、レンダリングエンジンに依存するあらゆるビジュアルコンテンツが脆弱性となる可能性があります。
2020年7月の同じパッチサイクルでは、Hyper-Vのいくつかの重大な脆弱性（CVE-2020-1041、-1040、-1032、-1036、-1042、-1043）も発表され、組織が厳格なパッチ管理プログラムを維持していない場合、さまざまなWindowsコンポーネント（ネットワーク、仮想化、グラフィックス）が同じ攻撃チェーンのリンクになる可能性があることが示されました。
Windowsシステムへの実際の影響、影響を受けるバージョン、およびベクトル
GDIの脆弱性の影響を受けるバージョンの範囲は広範です。Project Zeroが記録したゼロデイ脆弱性の事例では、gdi32.dllの脆弱性により、Windows Vista SP2、Windows 7、Windows 8.1、Windows 10、および複数のWindows Serverエディション（2012 R2、2016など）が影響を受けました。つまり、家庭用および企業用の膨大な数のコンピューターが、ドキュメントを開いたり、Internet Explorerでブラウジングしたり、Office Onlineを使用したりするだけで、メモリリークの被害に遭う可能性があるということです。
最新のブルースクリーンエラー（BSOD）に関するシナリオにおいて、Microsoftは、分析された脆弱性がWindows 10（バージョン1607以降）、Windows 11、およびWindows Server 2016/2019/2022（Enterprise、Education、LTSCエディションを含む）に影響することを確認しました。Windows 7や8.1など、サポート期間が終了したバージョンは公式パッチの対象外ですが、これはGDIの問題がないという意味ではなく、単に定期的な修正プログラムが提供されないという意味です。
運用レベルでは、その影響は情報漏洩（本来非公開であるべきメモリの読み取り）、サービス拒否（繰り返し発生するブルースクリーンエラー）、およびリモートコード実行の3つのカテゴリに集約されます。企業環境では、重要な役割を担うサーバー（共有プリントサーバーやHyper-Vホストなど）でブルースクリーンエラーが発生すると、印刷サービスの停止、仮想マシンの予期せぬシャットダウン、リモートセッションでのデータ損失、復旧時間の長期化といった連鎖的な障害が発生する可能性があります。
ネットワークの観点から見ると、GDIは、受信したEMF/WMF画像やメタファイルを自動的に処理するサービスがある場合、SMB（ポート445）、RDP、WebDAVなどのプロトコルを介して悪用される可能性があります。ローカルでは、ペイント、ワードパッド、古い画像ビューア、あるいはファイルエクスプローラーでアイコンやサムネイルのプレビューに関わるプロセスなど、GDIを使用するアプリケーションでユーザーが悪意のあるファイルを開くだけで攻撃が行われます。最も一般的な攻撃手法は、フィッシングメールと、不正なEMFファイルを含むDOCXまたはPDFドキュメントを組み合わせたものです。
規制対象組織（金融、医療、行政など）では、パッチ未適用の脆弱性に起因するインシデントは、法的および規制上の影響を及ぼす可能性があります。重要なシステムをクラッシュさせるブルースクリーン（BSOD）は、サービス継続性を損なうセキュリティインシデントとみなされ、GDPRやHIPAAなどのフレームワークに関連する監査や罰則の対象となる可能性があります。さらに、さまざまな脅威インテリジェンスレポートでは、グラフィックサブシステムの脆弱性を悪用した攻撃は、アジアやヨーロッパの高価値ターゲットを狙うAPTグループによるものだと指摘されています。
業界の一般的なデータ（例えば、年次データ侵害報告書に反映されているデータ）によると、重要なアップデートがリリースされてから90日以上経過しても、かなりの割合のWindowsデバイスがパッチ未適用のままになっていることを覚えておく価値があります。これは、攻撃者がエクスプロイトを自動化し、脆弱なホストをネットワーク全体でスキャンできるMetasploitやCobalt Strikeなどのフレームワークに組み込むための大きな機会を与えてしまいます。
マイクロソフトが修正プログラムを配布する方法と、どのファイルが変更されるか
GDI に脆弱性が発見されると、Microsoft は通常、月次ロールアップにまとめられたセキュリティ更新プログラムをリリースします。これらの更新プログラムは通常、 Windows Update、Microsoft Update カタログ、または Windows Server Update Services (WSUS) や Microsoft Endpoint Configuration Manager (MECM) などの管理ツールを通じて提供されます。CVE-2017-11816 の脆弱性の場合、対応する更新プログラム (たとえば、Windows Server 2008 用の KB4042121) は、Windows Update またはカタログからスタンドアロンの .msu ファイルとして入手できます。
マイクロソフトが特に強調している点の一つは、アップデート適用後に言語パックをインストールした場合、セキュリティパッチを再インストールする必要があるということです。そのため、必要な言語パックを先にインストールしてからアップデートを適用することが常に推奨されます。この些細な点が、実際には特定のGDIバイナリに修正版が含まれていないにもかかわらず、システムがパッチ適用済みと誤解されるという事態を複数引き起こしています。
これらのセキュリティ情報に関するドキュメントでは、Microsoft はファイル情報（ファイル名（例: gdi32.dll）、バージョン、サイズ、日付、時刻、プラットフォーム（x86、x64、IA-64））を記載した詳細な表を提供しています。これらの表により、管理者と監査担当者は、正しいバイナリがインストールされているかどうかをフォレンジック的に検証できます。同様のプロセスは、Windows および Office の各エディションの .msu および .exe パッケージにも適用され、各ファイルの SHA1 および SHA256 ハッシュが一覧表示されるため、チームはファイルの整合性を検証できます。
ファイルとハッシュのリストは膨大です。Windows6.0 -KB2834886-x86.msuとその x64 および ia64 バリアントから、Windows6.1-KB2835364-x64.msu、Windows8-RT-KB2835361-x86.msu、あらゆる言語 (CHS、CHT、DEU、ESN、FRA、ITA、JPN、KOR、PTB、PTG、RUS など) の Windows Server 2003 および Windows XP 用の数十個のインストーラー、AttendeeAdmin.msp、ogl2007-kb2687309-fullfile-x86-glb.exe、lyncloc2013-kb2817465-fullfile-x64-glb.exe などの Office および Lync コンポーネントのパッチまで。それぞれが検証を容易にするために独自のSHA1およびSHA256ハッシュを組み込んでいる。
これらのケースすべてにおいて、最終的な目標は同じです。gdi32.dllファイル（または関連するグラフィックスサブシステムバイナリ）をセキュアバージョンに更新することです。たとえば、Windows Server 2008 のようなプラットフォームでは、gdi32.dll はバージョン 6.0.6002.24200 と表示され、サイズはアーキテクチャによって異なります（x86 では約 299.520 バイト、x64 では 391.680 バイト、IA-64 では 955.392 バイト）。これらの値とビルド日付は、システムにパッチが適用されているかどうかを判断するための基本的な基準となります。
公式ドキュメントには、これらの更新プログラムの実装と展開に関する詳細を記載したナレッジベースの記事、およびサポートリソースへのリンクも含まれています。サポートリソースには、Windows Update のヘルプページ、IT プロフェッショナル向けのセキュリティポータル (TechNet Security など)、国際サポートサイト、および Microsoft Secure ブランドの下でマルウェア対策を行うための特定のサービスなどが含まれます。
緩和、監視、対応のための優れた実践
パッチが利用可能になり次第インストールすることに加えて、特に数百台または数千台のコンピュータが存在する企業環境において、GDI障害に伴うリスクを軽減するのに役立つ、多くの緩和策や多層防御策が存在します。
まず、アプリケーションやブラウザーで特定のグラフィック形式の自動処理を無効化または制限することで、攻撃対象領域を限定することをお勧めします。たとえば、Microsoft Edge では、ダウンロード制限に関連するレジストリ キー HKLM\SOFTWARE\Policies\Microsoft\Edge を使用して、EMF/WMF メタファイルのダウンロードと処理をブロックまたは制御するグループ ポリシーを設定できます。その他のアプリケーションでは、構成オプションを使用して信頼できない場所からのドキュメントの自動プレビューを防止し、トラブルシューティング ガイドを適用してファイル エクスプローラーの応答しない問題を解決できます。
もう一つの重要なレイヤーは、ゼロトラストの原則に基づいたネットワークセグメンテーションです。これには、SMB、RDP、その他悪用される可能性のあるプロトコルトラフィックを必要最低限のサブネットのみに制限すること、ディープパケットインスペクションを備えた次世代ファイアウォールを実装すること、そしてIDとコンテキストに基づいたルールを適用することが含まれます。どのデバイスがどのサービスと通信できるかを制限することで、攻撃が横方向に拡散しようとする場合の影響を大幅に軽減できます。
検出面では、Microsoft Defender for Endpoint などのエンドポイント検出および対応 (EDR) ソリューションを導入することで、win32k.sys、gdi32.dll、およびブルースクリーンエラー (BSOD) イベントに関連する異常な動作を監視できます。ブルースクリーンエラーの急増 (たとえば、イベント ビューアーのイベント ID 1001 から始まる) やグラフィック サブシステムへの異常なアクセスに対するアラートを設定することで、マルウェアによる悪用試行や不安定性を特定できます。
パッチ管理に関しては、Windows Update for Business、WSUS、またはMECMを使用して展開を自動化することを強く推奨しますが、本番環境に移行する前に、ステージング環境でテストフェーズを必ず実施して潜在的な不具合を検出してください。エアギャップ環境においては、EMF/WMFやその他のグラフィカル形式のファイルにおける疑わしいパターンを認識するように設計されたYARAルールなどのツールを使用して、受信するすべてのファイルを監査することをお勧めします。
より高度なシナリオでは、一部の組織は、Direct2D、DirectWrite、またはクロスプラットフォームグラフィックスエンジン（Cairo、Skia）といった、より高度なAPIに社内アプリケーションを移行することを検討しています。これらのAPIは、より優れた分離性を提供し、従来のGDIへの依存度を低減します。中期的には、Microsoftは攻撃対象領域を縮小するために、将来のWindowsバージョンでGDIの重要な部分を非推奨にする可能性がありますが、古いソフトウェアとの互換性は依然として課題となるでしょう。
フォレンジックおよびリバースエンジニアリングの観点から、WinDbg、KD、Volatilityなどのツールを使用すると、BSOD（ブルースクリーン・オブ・デス）後のメモリダンプを解析し、カーネルメモリプール内の「Gdi」とラベル付けされたメモリの破損を観察できます。研究目的で公開された概念実証エクスプロイトは、特定の不正なレジスタ（EMR_HEADERなど）を持つEMF（エンジンメモリファイル）が、どのように競合状態を引き起こし、クラッシュをトリガーするかを示しています。この知識は、インシデント対応チームが実際の攻撃で何が起こったかを再現するために不可欠です。
インシデントが発生した場合は、NISTの（識別、封じ込め、根絶、復旧）などのアクションフレームワークに従うことを推奨します。これには、影響を受けたシステムの隔離、証拠（メモリダンプ、ログ、疑わしいファイルのサンプル）の保全、保留中のパッチの適用、最新のマルウェア対策ツールによるシステムのスキャン、検証済みのバックアップからの復元、または以前の状態へのロールバックが含まれます。さらに、システムのパッチ適用と強化プロセスを改善するために、定期的に教訓をレビューすることをお勧めします。
Windows GDI をめぐる一連の不具合とパッチ適用の歴史は、堅牢な階層型セキュリティおよび更新戦略がない場合、レガシーコンポーネントがいかに脆弱になり得るかを浮き彫りにしています。これらの脆弱性がどのように悪用されるか、どのバージョンが危険にさらされているか、そしてどのような追加制御を適用できるかを理解することで、管理者とサイバーセキュリティ専門家はシステムを強化し、単純なイメージや特別に細工されたメタファイルによって Windows インフラストラクチャがクラッシュしたり、完全に侵害されたりするのを防ぐことができます。
