미리 이 버그 헌팅 여정의 끝을 스포하자면, 우리는 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 메소드는, 총 네 개의 인자를 받으며, 그중 네 번째 인자로 VARIANT 포인터를 전달 받습니다. [1]과 [2]에서 사용자가 입력한 VARIANT의 vt 필드와 데이터 필드를, v12 와 v12 + 0x8에 저장합니다. 이후 해당 데이터는SetLanguageOperationStateInRegistry 메소드의 세 번째 인자로 전달되어 사용됩니다.

SetLanguageOperationStateInRegistry 메소드에서는 [1]에서 a2가 0이면, [2]에서 data의 값을 사용자가 입력한 VARIANT의 데이터 필드로 저장합니다. 그리고 data의 주소를 SetRegValue 함수의 여섯 번째 인자로 사용합니다.

그리고, data 값은 RegSetKeyValueW 함수의 다섯 번째 인자로 사용됩니다.

그렇다면 RegSetKeyValueW 함수는 어떤 함수일까요? RegSetKeyValueW 함수는, 지정한 레지스트리 키에 값을 생성하거나 수정할 때 사용됩니다.

즉, 여기서는 Status라는 레지스트리 키에 우리가 인자로 전달한 VARIANT의 데이터 필드를 4byte 만큼 적는 것이죠.

그런데 무언가 이상하지 않나요? 지금까지 우리가 봤던 코드에는 SetLanguageOperationStateInRegistry 메소드에서 a2가 0일 때, VARIANT의 데이터 타입을 검증하는 부분이 존재하지 않습니다. 그렇다면 만약, VARIANT의 데이터 타입이 BSTR과 같이, 포인터를 가리키는 값이면 어떻게 될까요?

바로 이 부분에서, Type Confusion이 발생하게 됩니다. Registry Key에는 0과 1 같은 정수 값이 적히는 것이 아닌, 데이터의 하위 4byte 주소가 적히게 됩니다.

해당 레지스트리 경로는, 일반 유저 권한에서 읽을 수 있기 때문에, 하위 4byte 주소를 유출할 수 있습니다.

개인적으로, 재미있는 취약점인 거 같습니다. 이 버그는 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;
}

이제, 획득한 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;
}

바로 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);
    }
}

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

우리는 Race Condition 취약점을 계속해서 찾기 위해, Windows Print Workflow를 담당하는 PrintWorkflowUserSvc로 여정을 떠났습니다. 우리는 이 서비스에서 다양한 취약점을 발견할 수 있었습니다. 그 중 두 개의 취약점에 대해 소개하겠습니다.

첫 번째 취약점은 Use-After-Free 취약점입니다. 취약점은 CWorkflowSession 객체의 SetPrintTicket 메소드에서 발생합니다.

*((_QWORD *)this + 10) 에는 이전에 SetPrintTicket 호출에서 할당된 힙 주소가 저장됩니다. 하지만 CWorkflowSession COM 인터페이스는 MTA 모델에 속해있기 때문에 서로 다른 스레드에 의해 동시에 접근할 수 있습니다. 따라서 적절한 락 메커니즘이 존재하지 않으므로 레이스 컨디션을 통해 다음과 같은 형태로 Use-After-Free 혹은 Double Free가 발생할 수 있습니다.

몇 가지 제약 사항으로 인해 해당 취약점은 성공적으로 익스플로잇 하지 못했으나, 몇 가지 아이디어를 사용하면 개념적으로 익스플로잇이 가능해 보입니다.

먼저 ASLR bypass 입니다. ASLR의 경우 공격자가 컨트롤 하는 프로세스와 상위 권한의 프로세스의 동일한 DLL은 같은 가상주소에 매핑 되기 때문에 적절한 수준의 주소 정보를 알아 낼 수 있습니다. 이러한 아이디어는 IPC 메커니즘을 통한 LPE, SBX Escape에서 가장 기본이 되는 아이디어입니다.

두 번째로는 힙 주소 유출입니다.CWorkflowSession에는 다른 메소드가 노출되어있고 이중 this + 10 주소에 접근하는 다른 메소드가 있는지 확인해 보았습니다. 그리고 마침내 다음과 같은 함수를 찾았습니다.

즉 이미 해제된 this + 10 에 있는 값을 Output Buffer에 완전히 안정적인 크기로 복사해주는 것을 알 수 있습니다. 즉 다음과 같은 시나리오로 유용한 힙 주소를 가져 올 수 있습니다.

먼저 총 세 개의 스레드가 필요합니다. 각각 그림과 같이 COM Interface를 호출하게 됩니다. 스레드 2에서 만약 this + 10에 값이 존재하면 SetPrintTicket에서 이미 존재하는 힙을 해제하게 됩니다. 이후 스레드 3에서 정상 할당이 진행되기 전에 vftable을 가지거나 힙 주소가 존재하는 객체를 할당하게 된다면 스레드 1에서 GetPrintTiket을 통해 this + 10 주소를 참조하기 때문에 Victim 객체의 값을 성공적으로 공격자에게 리턴 할 수 있습니다. 공격자는 힙이 할당되는 사이즈 필드를 SetPrintTicket에서 완전히 제어할 수 있기 때문에 Victim 객체의 크기 제약이 없어, Race Windows 내부에서 해제된 hole에 넣는 것은 매우 확정적으로 수행됩니다.

다음으로 RIP control은 어떻게 수행될 수 있을까요? 앞에서 설명한 힙 주소 유출 방법과 비슷한 방식으로 Corrupted된 vftable을 만들어 낼 수 있습니다.

총 세 개의 스레드가 사용됩니다. 앞선 방식과는 다르게 두 개의 스레드는 SetPrintTicket을 통해 레이스를 시작합니다. 먼저 this + 10 이 null이 아니라면 힙을 해제하게 됩니다. 이 사이에 임의의 객체를 할당하여 해당 Hole에 들어가게 합니다. 다음으로 공격자가 완전히 컨트롤 가능한 값과 사이즈로 해당 Victim 객체를 덮을 수 있습니다. 해당 객체에 vftable이 존재한다면 성공적으로 RIP를 조작할 수 있게 됩니다.

이러한 아이디어에도 불구하고 우리는 완전히 동작하는 익스플로잇을 개발하지 못했습니다. 우리가 마주한 몇 가지 문제는 다음과 같습니다.

만약 Race Condition을 통해 해제된 위치에 Victim 객체를 할당하고 성공적으로 덮어썼다고 가정하여도 Double Free로 인해 발생하는 메모리 충돌을 피하기 매우 힘들고, Race Window가 매우 작아 정밀한 컨트롤이 매우 힘들었습니다.

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

이제 마지막 취약점을 소개하고자 합니다. 이전 Case와 마찬가지로 PrintWorkflowUserSvc에서 발생합니다. IPrintSupportSourceSession 클래스의 RequestSpoolingHandlesForWrite 메소드를 살펴보겠습니다. 해당 메소드는 a2부터 a7까지 총 6개의 인자를 받으며, 모든 인자가 결과 값이 반환되는 Output Parameter로 사용됩니다. 여러분들은 버그를 찾을 때 Input Parameter가 하나도 존재하지 않는 함수를 분석하시나요? 우리의 대답 또한 아니오였습니다. 물론, 이 취약점을 찾기 전까지는 말입니다.

이 함수는 [1]에서 this에 저장되어 있는, WorkflowSessionCommon의 vftable을 가리키는 주소를 v9에 저장합니다. 그리고, 해당 주소를 인자로 하여, [2]에서 WorkflowSessionCommon 클래스의 RequestSpoolingHandlesForWrite 메소드를 호출합니다.

이 메소드에서는 [1]에서 클라이언트의 PID를 가져와 [2]에서 클라이언트 프로세스의 핸들을 얻습니다. 이후, [3]에서 v22에 this를 참조하여 어떤 값을 저장하고, [4]에서 DuplicateHandle 함수를 호출합니다. 어라? DuplicateHandle 함수요?

DuplicateHandle 함수는, 객체의 핸들을 복제하는 Windows API 입니다. 함수 인자에 대한 설명을 요약하자면, 첫 번째와 두 번째 인자에 복제할 핸들을 소유한 프로세스 핸들과, 복제할 핸들이 들어갑니다. 그리고 세 번째에는 복제할 핸들을 받는 프로세스의 핸들이 들어가며 네 번째 인자에는 복제한 핸들의 값이 반환 됩니다. MSDN 설명에 의하면, PrintWorkflowUserSvc의 v22 핸들을, 클라이언트 프로세스의 복사하는 것을 뜻합니다. COM에서 이러한 패턴이 가끔 발견되기는 하지만, 보통은 콜백이나 메소드 구현을 위해 이벤트 핸들을 클라이언트 프로세스에 반환하고는 합니다.

v22 값이 실제로 어디서 세팅되는것은 간단한 리버스 엔지니어링을 통해 확인 할 수 있었습니다.

해당 값은 PrintSupportSession 클래스의 생성자에서 초기화되는 것으로 확인됐습니다. v22는 -1로 초기화됩니다. Windows에서 -1이라는 핸들은 자기 자신을 가리키는 의사 핸들 값을 뜻합니다.

즉, DuplicateHandle 함수에서 자신의 프로세스 핸들을, 클라이언트 프로세스에게 복제해주는 것을 의미합니다. 그렇다는 것은, PrintWorkflowUserSvc 보다 낮은 권한을 가진 클라이언트가 이 메소드를 호출하면, PrintWorkflowUserSvc의 핸들을 자신의 프로세스로 복제할 수 있습니다.

어떤 프로세스가 PrintWorkflowUserSvc에 접근할 수 있는지, 이 서비스의 Access Permission을 확인해 봤습니다. 확인해본 결과, 이 COM 객체는 모든 UWP 앱과, 특정 Capability를 가진 Low Privileged AppContainer에서도 접근할 수 있다는 것을 확인했습니다. 이 뜻은 Sandox된 프로세스에서 PrintWorkflowUserSvc의 프로세스 핸들을 자신에게 복제할 수 있음을 의미합니다.

이 취약점은 정말 완벽한 로직버그 입니다. 권한 상승을 위해 전에 설명했던 복잡한 Use-After-Free 취약점을 익스플로잇할 필요가 전혀 없습니다. 이제 우리는, 복제된 핸들을 이용해 PrintWorkflowUserSvc 메모리에 쉘코드를 작성하고, 이를 CreateRemoteThread API를 이용해 실행시킬 것입니다.

4.4.3 Exploit Demo

취약점을 시연하기 위해 Adobe Acrobat 샌드박스 내에서 실행되는 렌더러에서 임의 코드 실행을 수행할 수 있다고 가정하고, 쉘코드를 주입하여 Sandbox Escape를 수행했습니다. 이를 통해 AppContainer에서 Medium으로의 권한 상승에 성공하였습니다.

놀랍게도 이 버그는, MSRC로부터 “Exploit Less Likely” 판정을 받았습니다. 우리는 아직까지 MSRC가 왜 이런 판단을 내렸는지 잘 모르겠습니다.