미리 이 버그 헌팅 여정의 끝을 스포하자면, 우리는 10개 이상의 취약점을 MSRC에 제보하였고 CVE를 획득 할 수 있었습니다.

From this point on, we will walk you through the vulnerabilities we discovered during our bug hunting journey. To give you a quick preview: by the end of this journey, we reported over 10 vulnerabilities to MSRC and successfully earned several CVEs.

4.1 Four Key Vulnerabilities

다음은 우리가 소개할 총 4개의 버그입니다.

Next, we’ll introduce the four vulnerabilities we discovered.

• 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 메소드의 세 번째 인자로 전달되어 사용됩니다.

Let's move on to the first vulnerability. This vulnerability is a type confusion issue that occurs in the Windows LxpSvc (Language Experience Service). The vulnerability is triggered in the SetLanguageOperationState method of an internal class called DeviceLanguageManager.

The SetLanguageOperationState method takes four parameters, and the fourth parameter is a pointer to a VARIANT structure provided by the user. At steps [1] and [2], the method stores the vt field (the type information of the VARIANT) and the associated data field into v12 and v12 + 0x8, respectively. Later, this data is passed as the third argument to the SetLanguageOperationStateInRegistry method, where it is used without proper validation.

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

In the SetLanguageOperationStateInRegistry method, if a2 is zero at step [1], the method stores the user-provided VARIANT data field into the data variable at step [2].

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

Then, the address of data is passed as the fifth argument to the SetRegValue function

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

So, what is the RegSetKeyValueW function? The RegSetKeyValueW function is used to create or modify a value under a specified registry key.

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

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

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

In other words, at this point, the Status registry key is updated by writing 4 bytes of data from the VARIANT's data field that we provided.

But doesn’t something seem strange here? If you think back to the code we’ve seen so far, you’ll notice that when a2 is zero in the SetLanguageOperationStateInRegistry method, there is no validation of the VARIANT's data type at all!

Now, what would happen if the VARIANT's type was something like BSTR, which holds a pointer instead of a simple integer? This is exactly where Type Confusion occurs. Instead of writing an integer value like 0 or 1, the lower 4 bytes of the pointer address are written into the registry key.

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

Since this registry path is readable from a user-level context, it allows an attacker to leak the lower 4 bytes of a pointer address.

개인적으로, 재미있는 취약점인 거 같습니다. 이 버그는 MSRC로부터 나중에 패치 될 것이라는 답변을 받았습니다.

Personally, I think this was a really interesting vulnerability. Although MSRC determined that the report did not meet their bar for immediate security servicing, they committed to addressing the issue in a future version

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]에서 객체가 생성되어 클라이언트에게 반환됩니다.

The next vulnerability is a Double Free Bug found in the Windows Update Stack. The vulnerability occurs in the put_CrossGenSetId method of an internal class called FulfillmentDataInfo.

To trigger the vulnerable function, we first need to call the CreateFulfillmentData method of the InstallControl class, which will return an IFulfillmentDataInfo object. The condition for obtaining this object is very simple: At step [1], it checks whether the length of the string we provide as a2 is exactly 12. If the condition is met, the object is created at step [2] and returned to the client.

// 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]에서 해제 합니다. 그런데, 이 패턴을 어디서 많이 보신 거 같지 않나요?

Now, let's take a look at the put_CrossGenSetId method of the FulfillmentDataInfo object. At step [1], the method loads the HSTRING variable stored at this + 200 into v3. Then, at step [2], it frees the memory pointed to by v3. Wait.. doesn’t this look like a pattern we've seen before?

__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년이 지난 지금까지도 여전히 동일한 패턴의 취약점이 남아있었습니다. 이로써 우리가 선행 연구에서 느꼈던 의구심이 확신으로 바뀌는 순간이었습니다.

This issue is very similar to CVE-2020-1146, which was previously introduced in COMRace paper. Even after five years, vulnerabilities following the same pattern still remain. This was the moment when our initial suspicions, based on prior work, turned into certainty — there are still many types of race condition vulnerabilities left to be discovered.

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 메소드에서 발생합니다.

To continue hunting for race condition vulnerabilities, we turned our attention to PrintWorkflowUserSvc, the service responsible for managing the Windows Print Workflow. In this service, we were able to discover several vulnerabilities. Among them, we will introduce two of the most interesting cases.

The first vulnerability is a Use-After-Free issue. It occurs in the SetPrintTicket method of the CWorkflowSession object.

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

Looking at the code, we can see that *((_QWORD *)this + 10) holds a heap address that was allocated during a previous call to SetPrintTicket. However, because the CWorkflowSession COM interface belongs to the MTA (Multi-Threaded Apartment) model, the object can be accessed concurrently by different threads.

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

We attempted to exploit this vulnerability, but due to several constraints, we were not able to achieve a successful exploitation.

However, based on our analysis, we believe that with certain techniques and ideas, exploitation could be conceptually possible.

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

First, let's talk about bypass ASLR. In the case of ASLR, if the attacker-controlled process and the higher-privileged process load the same DLL, the DLL will be mapped at the same virtual address in both processes. This allows the attacker to infer a sufficient amount of address information.

This idea forms the fundamental basis for many LPE and sandbox escape techniques using IPC mechanisms.

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

Second, we needed a leak some heap addresss. Since the CWorkflowSession object exposes several other methods, I checked whether any of them could access the this + 10 address.

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

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

Eventually, I found a function that does exactly that. By using the GetPrintTicket method, we can copy the value located at this + 10 — which may already have been freed — into a output buffer. In other words, we can leak useful heap addresses through the following scenario.

First, we need a of three threads. Each thread will call different COM interface methods, as illustrated in the diagram. In Thread 2, if a value already exists at this + 10, calling SetPrintTicket will free the heap memory that was previously allocated there. Then, before a new allocation occurs, Thread 3 may allocate an object — such as one containing a vtable or any heap address — into the freed space.

After that, when Thread 1 calls GetPrintTicket, it will reference the this + 10 address, effectively leaking the value from the victim object back to the attacker. Since the size field for heap allocation can be fully controlled through SetPrintTicket, we can reliably place a victim object into the freed hole within the race window, without any size constraints.

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

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

Next, we move on to RIP control. Again, three threads are used. Unlike the previous leak scenario, here two of the threads start a race by both calling SetPrintTicket.

First, if this + 10 is not NULL, SetPrintTicket will free the heap memory stored there. During this window, an attacker can allocate an arbitrary object to occupy the freed hole. After that, the attacker can overwrite the victim object with fully controlled data and size. If the victim object contains a vtable, this can lead to successful control flow hijacking.

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

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

Even though we came up with these ideas, we were not able to develop a fully working exploit. We encountered several challenges:

First, even if we successfully allocated a victim object into the freed space through the race condition and managed to overwrite it, it was extremely difficult to avoid a double free situation.

Second, because both threads must call the same interface to trigger the race, and the race window is extremely narrow, precise control over the timing was very difficult to achieve.

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

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

Now, we would like to introduce the final vulnerability. Just like the previous cases, this vulnerability was also found in PrintWorkflowUserSvc.

Let's take a closer look at the RequestSpoolingHandlesForWrite method of the IPrintSupportSourceSession class. This method takes six parameters, from a2 to a7, and all of them are used as output parameters. Now, let me ask you:When you're hunting for bugs, do you usually bother analyzing functions that have no input parameters at all? Our answer was no — at least, until we discovered this vulnerability.

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

In this function, at step [1], the address of the WorkflowSessionCommon's vftable, which is stored in this, is loaded into v9. Then, using this address as an argument, the RequestSpoolingHandlesForWrite method of the WorkflowSessionCommon class is called at step [2].

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

In this method, at step [1], it retrieves the client's PID (Process ID). At step [2], it obtains a handle to the client's process. Then, at step [3], it references this again through v22 and stores some value. Finally, at step [4], it calls the DuplicateHandle function. Now it's time to see what Duplicatehandle function really works.

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

The DuplicateHandle function is a Windows API that duplicates a handle to an object. To briefly summarize the function arguments: the first and second parameters are the handle to the source process and the handle to be duplicated, respectively. The third parameter is the handle to the target process that will receive the duplicated handle, and the fourth parameter is where the newly duplicated handle will be returned. According to the MSDN documentation, this operation effectively means that the handle from v22 inside PrintWorkflowUserSvc is duplicated into the client process. While this pattern can sometimes be seen in COM, it is usually used to return event handles to the client process for implementing callbacks or method notifications.

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

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

It was confirmed by simple reverse engineering that the v22 value was actually set where. Through analysis, we found that it is initialized in the constructor of the PrintSupportSession class. The v22 value is set to -1. In Windows, a handle value of -1 represents a pseudo-handle that points to the current process itself.

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

This means that in the DuplicateHandle call, the handle of the PrintWorkflowUserSvc process is duplicated into the client process. In other words, if a lower-privileged client calls this method, it can successfully duplicate the PrintWorkflowUserSvc process handle into its own process.

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

Next, we checked which processes could access PrintWorkflowUserSvc by reviewing its access permissions. As a result, we found that this COM object is accessible not only by all UWP apps, but also by low-privileged AppContainer processes that have specific capabilities. This means that even a sandboxed process can duplicate the PrintWorkflowUserSvc process handle into its own process.

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

This vulnerability is truly a perfect logic bug. There is no need to exploit the complex Use-After-Free vulnerabilities we discussed earlier to achieve privilege escalation. Now, by using the duplicated process handle, we can write shellcode into the memory space of PrintWorkflowUserSvc and execute it by calling the CreateRemoteThread API.

4.4.3 Exploit Demo

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

Now it’s time for the demo. To demonstrate the vulnerability, we assumed a compromised renderer in the Adobe Acrobat sandbox and performed a sandbox escape by injecting shellcode, achieving a privilege escalation from AppContainer to Medium integrity level.

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

Surprisingly, the bug was declared "Exploit Less Likelly." We still don't know why the MSRC made this decision :D