moiz-2x/cve-2025-24990_pocProof of Concept CVE-2025-24990（Agere Systems のドライバー）
Windows Agere Modem ドライバー（ltmdm64.sys）。このドライバーは非常に古く、私のテストマシンではデフォルトで読み込まれないため、BYOVDシナリオで悪用します。興味深いことに、私の調査によると、このドライバーはWindows 7に存在し、少なくとも1つのバグがあります。こちら
当時、MSRCは何の対応も取りませんでした 🤡
このドライバー内の一部のIOCTLはMETHOD_NEITHERを使用していますが、呼び出し元が提供するアドレスバッファーがユーザーモード由来かカーネルモード由来かをチェックしていません。以下は、OSRでデコードしたIOCTLコードの例です：
つまり、DeviceIoControl APIにカーネルアドレスを指定でき、ドライバーはそれを通常通り処理します。
カーネルアドレスを漏洩させるには、まずkASLRをバイパスする必要があることに注意してください。EnumDeviceDriversを使用します（Windows 24h2ではこれを行うためにSeDebugPrivが必要です）。
問題はIOCTL 0x802b200f（ud_response）にあります。繰り返しますが、このIOCTLディスパッチはユーザーモードから提供するアドレスを検証しませんが、後でこれを活用します。
ud_response は ll_load_diagnostics を呼び出し、以下のコードに到達します：
最初に、グローバル変数 eeprom は初期化されていないため、NULLを含みます。これをトリガーする簡単なコードは次のとおりです。
これは後で活用します。
このIOCTLは、ドライバーのバージョン文字列 "8.36" を数値 0x836（DWORD）に変換し、呼び出し元が提供するアドレスに書き込みます（METHOD_NEITHERのおかげです）。技術的には、これらの4バイト（36 08 00 00）を任意のカーネルアドレスに書き込むことができます。これを利用して、ドライバーのグローバル変数を上書きし、実行フローを変更します。
この0x802b2003を IOCTL_GET_VERSION と呼びます。
任意のnull 1バイト：
NULL dereferenceのケースに戻り、VirtualAlloc APIを使用して固定アドレス（0x083600000000）を割り当てます。次に、IOCTL_GET_VERSIONを使用して、上記の4バイトを *(eeprom + 4) に書き込みます。ドライバーが後で eeprom を逆参照すると、割り当てたアドレスから読み取ります。
NULL dereferenceを修正した後、IOCTLはバッファーサイズに基づいて、ユーザーモードから提供するアドレスに文字列を書き込みます。
このコードは、上記で説明した内容を単に示しています。バッファーを割り当てて 0xAA で埋め、NULL dereferenceを修正してからドライバーを呼び出します。11バイトを割り当てますが、ドライバーにはバッファーサイズとして10のみを提供して、その動作を確認します。
サイズを10しか提供していないにもかかわらず、バッファーに固定バイト列を書き込み、最後のバイト（11番目）をnullにします。バッファー内の最後の 0xAA を 0x00 に置き換えます。これは、サイズ 0 を提供した場合でも、ドライバーがターゲットアドレスに単一の 0x00 バイトを書き込むことを示しています。
任意のデクリメント
これで、nullと固定4バイトの任意書き込みができたので、他のプリミティブを作成しましょう。
このIOCTLは、グローバル LtMsgEvent をユーザーバッファーに設定し、WDM がnullかどうかを確認してから、再度ゼロに設定します。
次に、0x802b2207で ObfReferenceObject APIを呼び出します。
初期状態では WDM はnullですが、IOCTL_GET_VERSION の助けを借りて WDM を 0x36（サイズは1バイトのみ）に設定でき、LtMsgEvent は依然としてユーザーバッファーです。次に WDM をnullにして0x802b2207を呼び出します。最後にObfReferenceObjectに到達します。この2つのIOCTLを IOCTL_SET_LtMsgEvent と IOCTL_DEREF_LtMsgEvent と呼びます。
ObfReferenceObject を使用したエクスプロイト技術は、KTHREAD の PreviousMode を UserMode から KernelMode に変更します。これについてはこちらで読むことができます。ただし、Windowsはこのエクスプロイトを修正したため、使用できません。
しかし、ObfReferenceObject のプリミティブはまだ存在します。このAPIは、提供するアドレスから 0x30 を減算し、結果を8バイト整数にキャストしてから1を減算します。
*(signed long long)(LtMsgEvent-0x30) -= 1
しかし問題は、次の値が 0 か、現在の値が < 1（8バイト符号付き整数として解釈）かをチェックすることです。いずれかの条件が真の場合、KeBugCheckEx にジャンプしてシステムをクラッシュさせます。
任意書き込み
任意デクリメントを手に入れたので、バイト 0xFF を書き込める別の場所を見つけて、それを目的のバイトにデクリメントする必要があります。このIOCTL 0x802b2243 を見つけました：
flip ブランチに焦点を当てます。pbVar5 はユーザーモードから提供するアドレスで、任意のターゲットアドレスにできます。バイト 0x0C を DAT_TARGET_EX に書き込み（IOCTL_GET_VERSION と任意デクリメントプリミティブの助けを借りて）、ターゲットアドレスの1バイトもnullにします。このIOCTLの最初の呼び出しでターゲットアドレスに 0xC0 が設定され、その後 0xBF にデクリメントされます。2回目の呼び出しでターゲットアドレスに 0xFF が設定されます（0xBF | 0xC0 = 0xFF）。ターゲットに 0xFF が含まれたら、目的の値にデクリメントするだけです。
1バイトずつ書き込み、ObfReferenceObject の KeBugCheckEx に注意します。
任意読み取り
読み取りプリミティブには、こちら（@carrot_c4k3）で説明されている手法を使用します。カーネル内の UNICODE_STRING オブジェクト（ExpManufacturingInformation）を上書きし、NtQuerySystemInformation を呼び出すだけです。ObfReferenceObject が KeBugCheckEx を呼び出すため、ExpManufacturingInformation に隣接する8バイトをnullにします。
これで完了です。任意のR/Wが手に入ったので、これらのプリミティブを使用して多くのことを行えます。ドライバーはデフォルトでは読み込まれないため、BYOVDシナリオで悪用し、プロセスのPPLを設定します。
上記で説明したエクスプロイトはすべてのWindowsバージョンで動作しますが、KeBugCheckEx のため不安定です。しかし、Windows 11 22h2+には ioring と呼ばれる手法があります。この手法は、ioring->Buffer を制御可能なアドレスで上書きするだけです。具体的には、ioring->Buffer とそのサイズをそれぞれ 0x083600000000 と 0x836 で上書きできます（IOCTL_GET_VERSION を使用）。この手法を使用すると、2回の書き込みのみで、R/Wプリミティブを非常に安定して使用できます。このアプローチではカーネルアドレスの漏洩が必要であることに注意してください。
Windowsはデフォルト状態ではドライバーを読み込みません。そのため、手動で読み込む必要があります。ファイル ltmdm64.sys は C:\Windows\System32\DriverStore\...\ltmdm64.sys にあります。管理者としてこのコマンドを実行し、エクスプロイトを実行します：
sc create ltmdm64_srv binPath="C:\Windows\System32\DriverStore...\ltmdm64.sys" type=kernel && sc start ltmdm64_srv
エクスプロイトはioring手法を使用してlsass.exeのPPLをオフにし、データのみの手法を使用してnotepad.exeにPPLを設定します（win 11 24h2ではSeDebugPrivが enabled である必要があります）
https://github.com/user-attachments/assets/05a35b38-d26c-484f-9fb7-137f8fe8c079
このバグをZDIに報告しました。しかし、Fabian Mosch と Jordan Jay のMSRCへの提出と重複しているようです。そのため、このPoCはバグを示すだけで、彼らの作業に感謝します。 ほぼ私の最初のCVEです 😍
