Recreate-cve-2023-21768

発生原因：202209版と202307版のAFD.sysを比較すると、関数AfdNotifyRemoveIOCompletionにおいて、202209版と202307版のWindowsの両方で、ProbeForWrite関数を使ってメモリ領域がユーザーモードかどうかをチェックしているステップがある。しかし、チェックされるバッファアドレスに0x8バイトの違いがある。本脆弱性のパッチ前にはこのチェックはなく、202209版のバッファチェックアドレスは正しくない可能性があり、無効かもしれない。そして、このチェックのバッファは途中の代入ステップに関係している：**(_DWORD **)(a3 + 24) = v20; ここでチェックされるべきバッファはa3+24であり、v20の値はv8 = IoRemoveIoCompletion(v25, Pool2, v4, (unsigned int)v6, &v20, a1, v13, 0)に関係している。少なくともPool2、v4、v13はユーザーモードから渡されたunknown structによって決まるように見えるので、v20の値もユーザーモードから渡されたstructに関係すると推測される~（writeupを見ると、IoRemoveIoCompletionがKeRemoveQueueExを呼び出した戻り値のようだ）。
そして、a3+24にカーネルモードのアドレスが格納されている場合、カーネル任意書き込み（kernel_arbitrary_write）プリミティブが発生し、さらにIORINGを使って悪用される可能性がある~（悪用方法：https://windows-internals.com/one-i-o-ring-to-rule-them-all-a-full-read-write-exploit-primitive-on-windows-11/）

再現環境：Visual Studio 2022でソースコードをコンパイル + Windows 11 202209（Hyper-V上で実行） コンパイルオプションはx64 Release。Hyper-V上でvcruntime140.dllが不足する問題があったため、静的リンクを採用。

AFD.sys内の関数利用チェーン：AfdFastIOdeviceControl -> AfdNotifySock -> AfdNotifyRemoveIOCompletion。unknown structの1つのフィールドにユーザーモードで決定されたアドレスを代入することで、任意のカーネル書き込み（arbitrary kernel Write-Where）プリミティブを作り出し、その後IORingによって悪用される。

expの実装：ArbitraryKernelWrite0x1関数を介して任意書き込み（arbitrary write）を実現する。exp内でこの関数の主要部分は、x86matthew氏の車輪の再利用により、Winsockをバイパスして直接AFD.sysとやり取りする（元々の車輪の目的はTCPソケットを直接作成すること）（https://www.x86matthew.com/view_post?id=ntsockets）。
上記で任意アドレス書き込みを実現しているのは、structAFD_NOTIFYSOCK_DATA（すなわち上記のunknown struct）であり、その各種構成要素は主に関数呼び出しチェーン内の各種チェックをバイパスするためのものである。
最初のパラメータであるハンドルの作成方法は、undocumentedなNT関数NtCreateIoCompletionによる（https://securityintelligence.com/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock/）

デバッグの所感を更新：見た目は似たようなコードでも、デバッグ時に奇妙な場所でハマることがある。
例えば、最初に_NtCreateFileを呼び出すとき、最初のパラメータにhSocketを渡すと、元の関数内の__imp_ObReferenceObjectByHandleが常に負の値を返す。調べてみると、別のハンドルを定義して_NtCreateFileと_NtDeviceIoControlFileのパラメータとして使う必要があった（これらの関数は主にafd.sysとのやり取りに使われるようで、x86matthewの記事を参照のこと）。
また、最初にNtSetIOCompletionを呼び出さなかったため、IORemoveIOCompletionのチェックにパスできなかった…ので、https://securityintelligence.com/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock/ の手法を参考にした。
さらに、shadowグループでシンボルテーブルがロードできない件について助言を求めたところ、原因はWindbgを実行しているPCがプロキシ（梯子）を経由していなかったため、オンラインのシンボルテーブルに接続できなかったことだった。
最後に、Windbgを使ってHyper-V上のプログラムをデバッグする方法は、Microsoft Learnで説明されているほど複雑ではない。おおよそ、bcdedit /debug on; bcdedit /dbgsettings net hostip:（ホスト側のEthernet default switchのIPv4アドレス） port:50001 key:1.2.3.4 をHyper-Vのコマンドラインに入力すればよい。
そのzipファイルには、再現用のVisual Studioの完全なプロジェクトが含まれている。

最後に、特に婷婷姐と、Windbgのトラブルシューティングを手伝ってくれたmimi先輩に感謝します。