脆弱性

インサイドWin32kエクスプロイト: CVE-2022-21882とCVE-2021-1732の分析

9 min read

図表の目次

図25. PoC 530行目
 図26. NtUserMessageCall呼び出し前のWndMagicのtagWND構造体
 図27. NtUserMessageCall呼び出し後のWndMagicのtagWND構造体
 図28. Wnd0のtagWND構造体
 図29. NtUserMessageCall呼び出し後のメモリーレイアウト
 図30. SetWindowLongWの関数プロトタイプ
 図31. PoC 534行目
 図32. PoC 542行目

10. NtUserMessageCallを呼び出してWndMagic上のフックされた関数をトリガーする

ここまでで任意のウィンドウオブジェクト(ステップ9で説明したようにここではWnd0)に対する潜在的なカーネルデスクトップヒープポインターを取得する準備ができたので、あとはフックされたユーザーモードコールバックxxxClientAllocWindowClassExtraBytesを呼び出す関数を見つけるだけです。

ここでこのxxxClientAllocWindowClassExtraBytesは、CVE-2021-1732で悪用されたものと同じユーザーモードコールバックであることを念頭に置くとよいでしょう。あちらの場合、xxxClientAllocWindowClassExtraBytesはxxxCreateWindowEX内で呼び出される前にフックされていました。xxxCreateWindowEXは、CreateWindowファミリーのいずれかの関数の呼び出した後で呼び出されます。

この脆弱性を緩和する修正プログラムの一部としてMicrosoftはxxxCreateWindowEX内にチェックを追加し、ユーザーモードコールバック中にtagWND.dwExtraFlag(ステップ7で解説)が変更されないようにしました。ですがたとえば、Microsoftが修正していない、xxxClientAllocWindowClassExtraBytesを呼び出す関数がほかにもあったとしたらどうでしょうか。

CVE-2022-21882の場合、NtUserMessageCallが、そうした関数の1つであることがのちに特定されました。実際、CVE-2022-21882を発見した人物は、単にCVE-2021-1732の修正プログラムをレビューして脆弱性の原因を特定した上で、「xxxClientAllocWindowClassExtraBytesを呼び出すほかの関数のなかには、まだtagWND.dwExtraFlagの検証を行う修正が反映されていないものがあるのではないか」と考え、それらの関数を確認した可能性が高いものと思われます。

NtUserMessageCallの呼び出し(行530)を図25に示します。使用されているパラメーターは、最終的にxxxWrapSwitchWndProcを実行させ、次にxxxSwitchWindowProcを実行させ、さらにxxxClientAllocWindowClassExtraBytesを呼び出します。

画像25は、PoC 530行目のスクリーンショットです。NtUserMessageCallを呼び出しています。 — 図25 PoC 530行目

これでxxxClientAllocWindowClassExtraBytesが悪意のある関数にフックされたので、NtUserMessageCallの呼び出しはg_newxxxClientAllocWindowClassExtraBytesの呼び出しにつながります。この結果、WndMagicはコンソールウィンドウに変換され、そのpExtraBytesはWnd0のカーネルデスクトップヒープベースオフセットに設定されます。これは、WndMagicのtagWND.pExtraBytes値への参照はすべてWnd0のカーネルデスクトップヒープの位置を指すことを意味します。

あるウィンドウのpExtraBytesフィールドを変更する方法があるなら、同じ方法でエクスプロイトを有効にして、少なくともtagWND.cbWndExtraフィールドに格納されているtagWND.pExtraBytesの長さまでは、Wnd0のtagWND構造体を変更できるようになります。実際、SetWindowLong関数ファミリーはまさにこの目的のために作られています。

NtUserMessageCall呼び出し前後のWndMagicのtagWND構造体のメモリーレイアウトをそれぞれ図26と図27に示します。

画像26は、NtUserMessageCall呼び出し前のWndMagicのtagWND構造体のスクリーンショットです。黄色い枠で「018」をハイライトしています。 — 図26. NtUserMessageCall呼び出し前のWndMagicのtagWND構造体

今WndMagicのtagWND.dwExtraFlagは 0x100100818で、これはうまくコンソールウィンドウに変換されたことを示しています。tagWND.pExtraBytesの値は0x2ad30に変更されています。

WndMagicはコンソールウィンドウになったので、この値はカーネルデスクトップヒープベースからのオフセットを表しています。ただし、これがWnd0が配置されているのと同じオフセットであることを思い出してください。これはつまり、WndMagicのtagWND.pExtraBytesフィールドは、カーネルデスクトップヒープ上のWnd0のtagWND構造体を指すようになったということです。

図28は、Wnd0のtagWND構造体とそのOffsetToDesktopHeapの値である0x2ad30を示しています。WndMagicのtagWND.pExtraBytesフィールドは今この値を指しています。

画像28は、Wnd0のtagWND構造体のスクリーンショットです。黄色い枠で0002ad30がハイライトされています。 — 図28. Wnd0のtagWND構造体

メモリーレイアウトと、この段階でのウィンドウのフィールド参照を図29に示します。

画像29は、NtUserMessageCall呼び出し直後のメモリーレイアウトを表す図です。左側がユーザーランドとそのレイアウト、右側がカーネルランドです。 — 図29. NtUserMessageCall呼び出し後のメモリーレイアウト

11. SetWindowLongAを使って任意のwriteプリミティブを作成する(PoC 534〜542行目)

図30に示すように、SetWindowLongW関数はウィンドウハンドルを最初のパラメーターとして受け取ります。パラメーターnIndexは、tagWND.pExtraBytesのメモリー割り当てのインデックスです。

標準ウィンドウの場合、このインデックスはtagWND.pExtraBytesに格納されたポインターからのオフセットとして参照されます。ですがコンソールウィンドウの場合、このインデックスはtagWND.pExtraBytesに格納されているオフセット値とカーネルデスクトップヒープベースから参照されます。最後のパラメーターdwNewLongは、nIndexにあるメモリーを変更する値です。

画像30はSetWindowLongW関数プロトタイプのスクリーンショットです。 — 図30. SetWindowLongWの関数プロトタイプ

したがって、ウィンドウの追加バイトの内容を変更するには、SetWindowLongWを呼び出せばよいことになります。WndMagicに対してSetWindowLongWが呼び出されると、SetWindowLongWはWndMagicのtagWND.pExtraBytes内にあるオフセットを処理実行用のメモリー空間として参照します。

要するに、WndMagicをHWNDパラメーターとしてSetWindowLongWを呼び出した場合、Wnd0のtagWNDベースアドレスにnIndexが設定されたオフセット値を加えた範囲内にあるメモリーが変更されることになります。これは、WndMagicのpExtraBytesが現在Wnd0のtagWNDベースを指しているためです。

図31に示すSetWindowLongWの最初の呼び出し(行534)では、WndMagicへのハンドルが渡され、オフセット0x128 + 0x10が、ステップ6でWnd0へのオフセットとして定義されたkernel_desktop_heap_base_offset_Minに変更されています。このオフセットは、実際には0x128のオフセットに過ぎません。なぜ0x10が含まれているかについては、以下の注を参照してください。

ただし、WndMagicのpExtraBytesオフセットはWnd0を参照しているため、このSetWindowLongWへの呼び出しはWnd0のオフセット0x128(tagWND.pExtraBytes)を自身のtagWND.OffsetToDesktopHeapのオフセットに変更します。したがって、これ以降Wnd0でSetWindowLongファミリーの関数を呼び出す場合、機能的にはWnd0のtagWND構造体の開始位置からの相対オフセットで操作することになります。

また、SetWindowLongWとSetWindowLongPtrへの呼び出しは、その関数呼び出しが行われる前の、指定されたオフセット(nIndex)の以前の値を返すことにも注意が必要です。したがって、dwRet変数(図31に示す)は、SetWindowLongWを呼び出す前のWnd0(上の図16に示す0x2ae80)のtagWND.pExtraBytesと等しくなります。

注: 0x10の追加は、xxxSetWindowLongW内で行われる減算を考慮したものです。これは奇妙に思えるかもしれませんが、これらの関数はサードパーティコードからの呼び出しを想定していないので、Microsoftはとくにコードをユーザーフレンドリーなものに変更する必要性を感じていない点を思い出してください。

画像31は、PoC 534行目のスクリーンショットです。これは DWORD dwRet = SetWindowLongW で始まっています。 — 図31 PoC 534行目

図32に示すSetWindowLongWへの次の呼び出し(542行目)では、Wnd0のtagWND.cbWndExtraフィールドを0xFFFFFFFに変更しています。cbWndExtraフィールドがpExtraBytesフィールドのサイズを定義していることを思い出してください。これによって、追加のバイトフィールドサイズが非常に大きな数字になります。これにより、オーバーフローの条件が有効になり、エクスプロイトによる隣接するカーネルメモリーへの書き込みが可能になります。