Integer Overflow Vulnerability in Windows Driver Enables Privilege Escalation, PoC Published

### #KernelExploitation #PrivilegeEscalation #WindowsVulnerability

Summary: A critical vulnerability in the ksthunk.sys driver of Windows allows local attackers to exploit an integer overflow for privilege escalation, demonstrated at the TyphoonPWN 2024 event. Despite Microsoft’s claims of resolution, the flaw remains exploitable in Windows 11 23H2.

Threat Actor: Advanced Threat Actors | Advanced Threat Actors
Victim: Microsoft Windows | Microsoft Windows

Key Point :

  • The vulnerability arises from a lack of integer overflow validation in the CKSAutomationThunk::ThunkEnableEventIrp function.
  • Attackers can manipulate memory to create gaps, allowing for arbitrary read and write capabilities.
  • Exploitation can lead to token overwrite, granting SYSTEM privileges and full control over the affected machine.
  • No CVE number or detailed patch information has been provided, highlighting the ongoing risk.
  • This incident underscores the critical need for rigorous validation in kernel-level code to prevent such vulnerabilities.

An independent researcher has uncovered a critical vulnerability in the ksthunk.sys driver, a component of the Windows operating system responsible for facilitating 32-bit to 64-bit process communications. The flaw, which allows a local attacker to exploit an integer overflow for privilege escalation, has been successfully demonstrated and highlighted during the prestigious TyphoonPWN 2024 event, earning second place.

The vulnerability lies in the CKSAutomationThunk::ThunkEnableEventIrp function, which allocates buffers for managing input and output data within the kernel. The issue stems from a lack of integer overflow validation during buffer size alignment calculations. This oversight results in improperly sized allocations that trigger a heap overflow, enabling attackers to overwrite adjacent memory.

// Only Called when the calling process is 32bit.
__int64 __fastcall CKSAutomationThunk::ThunkEnableEventIrp(__int64 a1, PIRP a2, __int64 a3, int *a4)
{
...
inbuflen = CurrentStackLocation->Parameters.DeviceIoControl.InputBufferLength;
outbuflen = CurrentStackLocation->Parameters.DeviceIoControl.OutputBufferLength;
// [1]. Align the length of output buffer
outlen_adjust = (outbuflen + 0x17) & 0xFFFFFFF8;
if ( a2->AssociatedIrp.MasterIrp )
return 1i64;

if ( (unsigned int)inbuflen < 0x18 )
ExRaiseStatus(-1073741306);

ProbeForRead(CurrentStackLocation->Parameters.DeviceIoControl.Type3InputBuffer, inbuflen, 1u);
if ( (*((_DWORD *)CurrentStackLocation->Parameters.DeviceIoControl.Type3InputBuffer + 5) & 0xEFFFFFFF) == 1
|| (*((_DWORD *)CurrentStackLocation->Parameters.DeviceIoControl.Type3InputBuffer + 5) & 0xEFFFFFFF) == 2
|| (*((_DWORD *)CurrentStackLocation->Parameters.DeviceIoControl.Type3InputBuffer + 5) & 0xEFFFFFFF) == 4 )
{
// [2]. Validate the Length
if ( (unsigned int)outbuflen < 0x10 )
ExRaiseStatus(-1073741306);
if ( outlen_adjust < (int)outbuflen + 16 || outlen_adjust + (unsigned int)inbuflen < outlen_adjust )
ExRaiseStatus(-1073741306);

// [3]. Allocate the buffer to store the data
// 0x61 == POOL_FLAG_USE_QUOTA | POOL_FLAG_RAISE_ON_FAILURE POOL_FLAG_NON_PAGED
a2->AssociatedIrp.MasterIrp = (struct _IRP *)ExAllocatePool2(
0x61i64,
outlen_adjust + (unsigned int)inbuflen,
1886409547i64);
a2->Flags |= 0x30u;
ProbeForRead(a2->UserBuffer, outbuflen, 1u); // [*]
data = (__int64)a2->AssociatedIrp.MasterIrp;
...
// [4]. Copy the Data
if ( (unsigned int)outbuflen > 0x10 )
memmove((void *)(data + 0x20), (char *)a2->UserBuffer + 16, outbuflen - 16);
memmove(
(char *)a2->AssociatedIrp.MasterIrp + outlen_adjust,
CurrentStackLocation->Parameters.FileSystemControl.Type3InputBuffer,
inbuflen);
...
}

The SSD Secure Disclosure technical team explains: “At [1], there is no integer overflow validation while calculating outbuflen + 0x17. Therefore, outlen_adjust can be set to a small value, leading to an undersized allocation and eventual heap overflow during data copying at [4]

The exploit leverages a series of steps to bypass kernel safeguards and achieve system-level privileges:

  1. Memory Manipulation: Attackers create gaps between named pipe objects in the kernel’s non-paged pool, making it easier to exploit the overflow.
  2. Arbitrary Memory Access: By corrupting adjacent named pipes, attackers gain arbitrary read and write capabilities.
  3. Token Overwrite: Exploiters modify the current process token to gain SYSTEM privileges, allowing complete control over the machine

Microsoft was notified of the vulnerability, but the vendor claimed it was a duplicate issue that had already been resolved. Despite these assurances, the researcher found the flaw to still be exploitable on Windows 11 23H2. No CVE number or detailed patch information has been provided to date.

This vulnerability exemplifies the risks associated with kernel-level flaws. The ability to escalate privileges via a driver underscores the importance of rigorous validation in kernel code. As SSD Secure Disclosure noted, the exploitability of this flaw “is not hard” due to the controllable allocation sizes and data involved, making it a potential tool for advanced threat actors.

To read the technical details and proof-of-concept (PoC) code, please visit the official advisory from SSD Disclosure.

Related Posts:

Source: https://securityonline.info/integer-overflow-vulnerability-in-windows-driver-enables-privilege-escalation-poc-published