先にこのバグハンティングの旅の結末を明かしてしまうと、私たちは 10個以上 の脆弱性をMSRCに報告し、CVE を獲得することができました。

4.1 Four Key Vulnerabilities

以下は、私たちが紹介する計4つのバグです。

• Case 87975: Type Confusion in LxpSvc

• CVE-2025-27475: Double Free Bug in InstallService

• CVE-2024-49095: Use-After-Free in PrintWorkflowUserSvc

• CVE-2025-21234: Improper Input Validation in PrintWorkflowUserSvc

4.1.1 Case 87975: Type Confusion in LxpSvc

該当のバグは、Windows LxpSvc (Language Experience Service) で発生した Type Confusion （型の混乱）脆弱性です。脆弱性は、内部クラスである DeviceLanguageManager の SetLanguageOperationState メソッドで発生します。SetLanguageOperationState メソッドは、計4つの引数を受け取り、その中の4番目の引数として VARIANT ポインタを渡されます。[1] と [2] で、ユーザーが入力した VARIANT の vt フィールドとデータフィールドを、v12 と v12 + 0x8 に保存します。その後、該当データは SetLanguageOperationStateInRegistry メソッドの3番目の引数として渡されて使用されます。

SetLanguageOperationStateInRegistry メソッドでは、[1] で a2 が 0 の場合、[2] で data の値をユーザーが入力した VARIANT のデータフィールドとして保存します。そして、data のアドレスを SetRegValue 関数の6番目の引数として使用します。

そして、data 値は RegSetKeyValueW 関数の5番目の引数として使用されます。

では、RegSetKeyValueW 関数とはどのような関数でしょうか？RegSetKeyValueW 関数は、指定したレジストリキーに値を生成または修正する際に使用されます。

つまり、ここでは Status というレジストリキーに、私たちが引数として渡した VARIANT のデータフィールドを 4バイト分書き込むわけです。

ところで、何かおかしいと思いませんか？これまで私たちが確認したコードには、SetLanguageOperationStateInRegistry メソッドで a2 が 0 のときに、VARIANT のデータタイプを検証する部分が存在しません。では、もし VARIANT のデータタイプが BSTR のように、ポインタを指す値だった場合はどうなるでしょうか？

まさにこの部分で、Type Confusion が発生することになります。Registry Key には 0 や 1 のような整数値が書き込まれるのではなく、データのメモリ下位4バイトのアドレスが書き込まれてしまいます。

該当のレジストリパスは、一般ユーザー権限で読み取ることができるため、下位4バイトのアドレスを流出させることができます。

個人的に、とても興味深い脆弱性だと思います。このバグについて、MSRC からは「将来的にパッチが適用される予定である」という回答を受け取りました。

4.1.2 CVE-2025-27475: Double Free Bug in InstallService

次の脆弱性は、Windows Update Stack で発見された Double Free Bug（二重解放バグ） です。脆弱性は、内部クラスである FulfillmentDataInfo の put_CrossGenSetId メソッドで発生します。

まず、脆弱な関数を呼び出すためには、InstallControl クラスの CreateFulfillmentData メソッドを呼び出して IFulfillmentDataInfo オブジェクトを取得する必要があります。このオブジェクトを取得するための条件は非常に単純です。[1] でユーザーが入力した a2 文字列の長さが 12 であるかを検証します。条件を満たした場合、[2] でオブジェクトが生成されてクライアントに返されます。

// Hidden C++ exception states: #wind=63
__int64 __fastcall WindowsUpdate::Internal::InstallControl::CreateFulfillmentData(
        WindowsUpdate::Internal::InstallControl *this,
        HSTRING a2,
        struct WindowsUpdate::Internal::IFulfillmentDataInfo **a3)
{
  HSTRING v5; // [rsp+38h] [rbp+10h] BYREF

  v5 = a2;
  if ( Utils::IsValidProductId(a2, a2) ) // [1] Verify that a2 is 0xC bytes 
    return Microsoft::WRL::Details::MakeAndInitialize<WindowsUpdate::Internal::FulfillmentDataInfo,WindowsUpdate::Internal::IFulfillmentDataInfo,HSTRING__ *>(
             a3,
             &v5); // [2] Return IFulfillmentDataInfo object
  *a3 = 0LL;
  return 2147942487LL;
}

// Hidden C++ exception states: #wind=63
__int64 __fastcall WindowsUpdate::Internal::InstallControl::CreateFulfillmentData(
        WindowsUpdate::Internal::InstallControl *this,
        HSTRING a2,
        struct WindowsUpdate::Internal::IFulfillmentDataInfo **a3)
{
  HSTRING v5; // [rsp+38h] [rbp+10h] BYREF

  v5 = a2;
  if ( Utils::IsValidProductId(a2, a2) ) // [1] Verify that a2 is 0xC bytes 
    return Microsoft::WRL::Details::MakeAndInitialize<WindowsUpdate::Internal::FulfillmentDataInfo,WindowsUpdate::Internal::IFulfillmentDataInfo,HSTRING__ *>(
             a3,
             &v5); // [2] Return IFulfillmentDataInfo object
  *a3 = 0LL;
  return 2147942487LL;
}

// Hidden C++ exception states: #wind=63
__int64 __fastcall WindowsUpdate::Internal::InstallControl::CreateFulfillmentData(
        WindowsUpdate::Internal::InstallControl *this,
        HSTRING a2,
        struct WindowsUpdate::Internal::IFulfillmentDataInfo **a3)
{
  HSTRING v5; // [rsp+38h] [rbp+10h] BYREF

  v5 = a2;
  if ( Utils::IsValidProductId(a2, a2) ) // [1] Verify that a2 is 0xC bytes 
    return Microsoft::WRL::Details::MakeAndInitialize<WindowsUpdate::Internal::FulfillmentDataInfo,WindowsUpdate::Internal::IFulfillmentDataInfo,HSTRING__ *>(
             a3,
             &v5); // [2] Return IFulfillmentDataInfo object
  *a3 = 0LL;
  return 2147942487LL;
}

次に、取得した FulfillmentDataInfo オブジェクトの put_CrossGenSetId メソッドを確認してみましょう。[1] では this + 200 に保存されている HSTRING 変数を v3 に保存します。そして、これを [2] で解放します。ところで、このパターンはどこかで見た覚えがありませんか？

__int64 __fastcall WindowsUpdate::Internal::FulfillmentDataInfo::put_CrossGenSetId(
        WindowsUpdate::Internal::FulfillmentDataInfo *this,
        HSTRING a2)
{
  unsigned int v2; // ebx
  HSTRING *v3; // rdi

  v2 = 0;
  v3 = (HSTRING *)((char *)this + 200); // [1] Get HSTRING from this + 200
  if ( !a2 || a2 != *v3 )
  {
    WindowsDeleteString(*v3); // [2] Free HSTRING
    *v3 = 0LL;
    return (unsigned int)WindowsDuplicateString(a2, v3);
  }
  return v2;
}

__int64 __fastcall WindowsUpdate::Internal::FulfillmentDataInfo::put_CrossGenSetId(
        WindowsUpdate::Internal::FulfillmentDataInfo *this,
        HSTRING a2)
{
  unsigned int v2; // ebx
  HSTRING *v3; // rdi

  v2 = 0;
  v3 = (HSTRING *)((char *)this + 200); // [1] Get HSTRING from this + 200
  if ( !a2 || a2 != *v3 )
  {
    WindowsDeleteString(*v3); // [2] Free HSTRING
    *v3 = 0LL;
    return (unsigned int)WindowsDuplicateString(a2, v3);
  }
  return v2;
}

__int64 __fastcall WindowsUpdate::Internal::FulfillmentDataInfo::put_CrossGenSetId(
        WindowsUpdate::Internal::FulfillmentDataInfo *this,
        HSTRING a2)
{
  unsigned int v2; // ebx
  HSTRING *v3; // rdi

  v2 = 0;
  v3 = (HSTRING *)((char *)this + 200); // [1] Get HSTRING from this + 200
  if ( !a2 || a2 != *v3 )
  {
    WindowsDeleteString(*v3); // [2] Free HSTRING
    *v3 = 0LL;
    return (unsigned int)WindowsDuplicateString(a2, v3);
  }
  return v2;
}

これは、まさに COMRace で紹介された CVE-2020-1146 と非常に酷似しています。5年が経過した現在でも、依然として同一パターンの脆弱性が残されていました。これにより、私たちが先行研究で抱いた疑問が確信に変わる瞬間でした。

Windows::System::Internal::SignInContext::put_AuthData(*this, HSTRING a2) {
    Microsoft::WRL::Wrappers::HString::Set(this + 15, &a2);
}

__int64 HString::Set(HSTRING *newString, HSTRING *a2) {
    unsigned int v2;
    v2 = 0;
    if(!*a2 || *a2 != *newString) {
        WindowsDeleteString(*newString); // Delete
        *newString = 0;
        v2 = WindowsDuplicateString(*a2, newString);
    }
}

Windows::System::Internal::SignInContext::put_AuthData(*this, HSTRING a2) {
    Microsoft::WRL::Wrappers::HString::Set(this + 15, &a2);
}

__int64 HString::Set(HSTRING *newString, HSTRING *a2) {
    unsigned int v2;
    v2 = 0;
    if(!*a2 || *a2 != *newString) {
        WindowsDeleteString(*newString); // Delete
        *newString = 0;
        v2 = WindowsDuplicateString(*a2, newString);
    }
}

Windows::System::Internal::SignInContext::put_AuthData(*this, HSTRING a2) {
    Microsoft::WRL::Wrappers::HString::Set(this + 15, &a2);
}

__int64 HString::Set(HSTRING *newString, HSTRING *a2) {
    unsigned int v2;
    v2 = 0;
    if(!*a2 || *a2 != *newString) {
        WindowsDeleteString(*newString); // Delete
        *newString = 0;
        v2 = WindowsDuplicateString(*a2, newString);
    }
}

4.1.3 CVE-2024-49095: Use-After-Free in PrintWorkflowUserSvc

私たちは Race Condition（競合状態）脆弱性を引き続き探すため、Windows Print Workflow を担当する PrintWorkflowUserSvc へと調査の旅を進めました。私たちはこのサービスでいくつかの脆弱性を発見することができました。そのうち2つの脆弱性についてご紹介します。

1つ目の脆弱性は Use-After-Free (UAF) 脆弱性です。この脆弱性は CWorkflowSession オブジェクトの SetPrintTicket メソッドで発生します。

*((_QWORD *)this + 10) には、以前 SetPrintTicket の呼び出しで割り当てられたヒープアドレスが保存されます。しかし、CWorkflowSession COM インターフェースは MTA モデルに属しているため、異なるスレッドから同時にアクセスされる可能性があります。そのため、適切なロックメカニズムが存在しないことから、レースコンディションを通じて以下のような形で Use-After-Free または Double Free が発生する可能性があります。

いくつかの制約事項により、この脆弱性の悪用（エクスプロイト）には成功しませんでしたが、いくつかのアイデアを駆使すれば、コンセプト上は悪用が可能であると思われます。

まずは ASLR bypass（ASLRの回避）です。ASLR の場合、攻撃者が制御するプロセスと、上位権限のプロセスにおける同一の DLL は同じ仮想アドレスにマッピングされるため、適切なレベルのアドレス情報を把握することができます。このようなアイデアは、IPC メカニズムを介した LPE (ローカル権限昇格) や SBX Escape (サンドボックス回避) において、最も基本となる概念です。

2つ目は、ヒープアドレスの流出です。CWorkflowSession には他のメソッドも公開されているため、このうち this + 10 のアドレスにアクセスする他のメソッドがあるかを調査しました。そしてついに、以下のような関数を見つけました。

つまり、すでに解放された this + 10 にある値を、完全に安定したサイズで Output Buffer にコピーしていることが分かります。すなわち、以下のようなシナリオで有用なヒープアドレスを取得することができます。

まず、計3つのスレッドが必要です。それぞれ図のように COM インターフェースを呼び出すことになります。スレッド 2 において、もし this + 10 に値が存在すれば、SetPrintTicket はすでに存在するヒープを解放します。その後、スレッド 3 で正常な割り当てが行われる前に、vftable を持つかヒープアドレスが存在するオブジェクトを割り当てた場合、スレッド 1 では GetPrintTicket を介して this + 10 のアドレスを参照するため、Victim（標的）オブジェクトの値を攻撃者へ正常に返すことができます。攻撃者はヒープが割り当てられるサイズフィールドを SetPrintTicket で完全に制御できるため、Victim オブジェクトのサイズ制約を受けることがなく、Race Windows の内部で解放されたホール（空き領域）へと非常に確実に配置することができます。

続いて、RIP コントロール（実行フローの制御）はどのようにして実行できるでしょうか？先ほど説明したヒープアドレス流出の方法と似たような手法で、破損した（Corrupted）vftable を作り出すことができます。

計3つのスレッドが使用されます。先ほどの方法とは異なり、2つのスレッドは SetPrintTicket を介してレースを開始します。まず this + 10 が null でなければヒープを解放します。この間に任意のオブジェクトを割り当て、該当のホールに入るようにします。次に、攻撃者が完全にコントロール可能な値とサイズで、該当の Victim オブジェクトを上書きすることができます。該当オブジェクトに vftable が存在する場合、RIP の改ざんに成功することになります。

これらのアイデアにもかかわらず、私たちは完全に動作するエクスプロイトを開発することはできませんでした。直面したいくつかの課題は以下の通りです。

仮に Race Condition を通じて解放された位置へ Victim オブジェクトを割り当てて上書きに成功したとしても、Double Free によって発生するメモリ衝突を回避することが非常に困難であり、Race Window が非常に小さいために精密なコントロールが極めて難しかったのです。

4.1.4 CVE-2025-21234: Improper Input Validation in PrintWorkflowUserSvc

いよいよ、最後の脆弱性を紹介します。前のケースと同様に、PrintWorkflowUserSvc で発生します。IPrintSupportSourceSession クラスの RequestSpoolingHandlesForWrite メソッドを見てみましょう。該当のメソッドは a2 から a7 まで計6つの引数を受け取り、すべての引数が結果値を返す Output Parameter（出力パラメータ）として使用されます。皆さんはバグを探す際、Input Parameter（入力パラメータ）が1つも存在しない関数を分析しますか？私たちの答えもまた「ノー」でした。もちろん、この脆弱性を見つけるまでは、ですが。

この関数は、[1] で this に保存されている WorkflowSessionCommon の vftable を指すアドレスを v9 に保存します。そして、該当のアドレスを引数として、[2] で WorkflowSessionCommon クラスの RequestSpoolingHandlesForWrite メソッドを呼び出します。

このメソッドでは、[1] でクライアントの PID を取得し、[2] でクライアントプロセスのハンドルを取得します。その後、[3] で v22 に this を参照して何らかの値を保存し、[4] で DuplicateHandle 関数を呼び出します。おや？ DuplicateHandle 関数ですか？

DuplicateHandle 関数は、オブジェクトのハンドルを複製する Windows API です。関数の引数に関する説明を要約すると、第1引数と第2引数に、複製元となるハンドルを所有するプロセスのハンドルと、複製対象のハンドルが入ります。そして第3引数には複製されたハンドルを受け取るプロセスのハンドルが入り、第4引数に複製されたハンドルの値が返されます。MSDNの説明によると、PrintWorkflowUserSvc の v22 ハンドルを、クライアントプロセスにコピーすることを意味します。COMにおいてこのようなパターンは稀に見られますが、通常はコールバックやメソッドの実装のためにイベントハンドルをクライアントプロセスに返すケースが多いです。

v22 値が実際にどこでセットされているかは、簡単なリバースエンジニアリングを通じて確認することができました。

該当の値は、PrintSupportSession クラスのコンストラクタで初期化されていることが確認されました。v22 は -1 に初期化されます。Windows において -1 というハンドルは、自分自身を指す疑似ハンドル（Pseudo Handle）の値を意味します。

すなわち、DuplicateHandle 関数において、自身のプロセスハンドルをクライアントプロセスに対して複製していることを意味します。ということは、PrintWorkflowUserSvc よりも低い権限を持つクライアントがこのメソッドを呼び出すと、PrintWorkflowUserSvc のハンドルを自身のプロセスとして複製できてしまいます。

どのようなプロセスが PrintWorkflowUserSvc にアクセスできるのか、このサービスの Access Permission (アクセス権限) を確認してみました。その結果、この COM オブジェクトはすべての UWP アプリや、特定の Capability を持つ Low Privileged AppContainer（低権限アプリコンテナ）からもアクセス可能であることを確認しました。これは、サンドボックス化されたプロセスからでも PrintWorkflowUserSvc のプロセスハンドルを自プロセスに複製できることを意味します。

この脆弱性は、本当に完璧なロジックバグです。権限昇格のために、前述したような複雑な Use-After-Free 脆弱性を悪用（エクスプロイト）する必要は全くありません。あとは、複製されたハンドルを利用して PrintWorkflowUserSvc のメモリにシェルコードを書き込み、それを CreateRemoteThread API を利用して実行するだけです。

4.4.3 Exploit Demo

脆弱性を実証するため、Adobe Acrobat のサンドボックス内で実行されるレンダラーから任意コード実行が遂行可能であると仮定し、シェルコードを注入して Sandbox Escape（サンドボックス回避）を実行しました。これにより、AppContainer から Medium 権限への昇格に成功しました。

驚くべきことに、このバグは MSRC から “Exploit Less Likely（悪用の可能性は低い）” と判定されました。私たちは未だに MSRC がなぜこのような判断を下したのかよく分かっていません。