Know About WDM?
Windows Driver Model (WDM) is the oldest and still the most-used driver framework. Every driver is essentially a WDM driver; the newer framework Windows Driver Framework (WDF) encapsulates WDM, simplifies the development process and deals with WDM’s multiple technical difficulties. The primary thing we care about while inspecting WDM drivers is how we can communicate with them; almost every bug in drivers involves some communication from an unprivileged user to the driver itself.
We start at the beginning, which in our case, is the entry point of our driver named “testy”:
DriverEntry(IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)
{
UNICODE_STRING DeviceName, SymbolicLink,sddlString;
PDEVICE_OBJECT deviceObject;
RtlInitUnicodeString(&DeviceName, L"\\Device\\testydrv");
RtlInitUnicodeString(&SymbolicLink, L"\\DosDevices\\testydrv");
RtlInitUnicodeString(&sddlString, L"D:P(A;;GA;;;SY)(A;;GA;;;BA)");
UNREFERENCED_PARAMETER(RegistryPath);
//Create a device
IoCreateDevice(DriverObject, 65535, &DeviceName, FILE_DEVICE_UNKNOWN, 0, FALSE, &deviceObject);
//IoCreateDeviceSecure(DriverObject, , &DeviceName, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &sddlString, NULL, &deviceObject);
//Create a symbolic so the user can access the device
IoCreateSymbolicLink(&SymbolicLink, &DeviceName);
//Populating Driver's object dispatch table
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = TestyDispatchIoctl;
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = TestyInternalDispatchIoctl;
DriverObject->MajorFunction[IRP_MJ_CREATE] = TestyDispatchCreate;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = TestyDispatchClose;
DriverObject->MajorFunction[IRP_MJ_READ] = TestyDispatchRead;
DriverObject->MajorFunction[IRP_MJ_WRITE] = TestyDispatchWrite;
DriverObject->MajorFunction[IRP_MJ_CLEANUP] = TestyDispatchCleanup;
DriverObject->DriverUnload = TestyUnloadDriver;
return STATUS_SUCCESS;
}
This code is an ordinary skeleton of the DriverEntry function that every WDM driver has. The first parameter is the DriverObject structure pointer used in device creation and dispatch routine initialization. Next, the driver has the MajorFunction member, which is a function pointer array used to assign dispatch routines for different events. Additionally, we have the critical device creation routines that we cover in the next section.
Device Creation and Initialization
As we said, the driver starts with creating a device by calling IoCreateDevice; this will create a DEVICE_OBJECT in the Object Manager. In Windows, a device object represents a logical, virtual or physical device for which a driver handles I/O requests. All of that sounds good, but it is not enough if we want it to communicate from a regular user standpoint; for this, we call IoCreateSymbolicLink that will create a DoS device name in the Object Manager that enables the user to communicate with the driver via the device. Some devices, however, don’t have normal names; they have autogenerated names (done in PDOs). They might look odd to the inexperienced bug hunter, so if you see them at first in your favorite device, view software and see the 8-hex in the device name column. These devices can interact like every other named device.
The most important things to note in the device creation routine are if the programmer assigned an ACL to the device and the value of DeviceCharacteristics.
Unfortunately, the IoCreateDevice method doesn’t allow the programmer to specify any ACL whatsoever, which is not good. As a result, the developer must define an ACL in the registry or the ini file of the driver. If they fail to do so, any user can access the device. Using the IoCreateDeviceSecure method, however, would mitigate that.
Besides that, we need to look at the fifth argument, which is DeviceCharacteristics . If the value of DeviceCharacteristics isn’t ORed with 0x00000100, FILE_DEVICE_SECURE_OPEN, here we likely face a security vulnerability (unless we talk about file system drivers or any that support name structure). The reason behind this is the way Windows treats devices; every device has its very own namespace. Names in the device’s namespace are paths that begin with the device’s name. For a device named \Device\DeviceName, its namespace consists of any name of the form “\Device\DeviceName\anyfile.”
A call IoCreateDevice without the FILE_DEVICE_SECURE_OPEN flag as in figure 1 means that the device ACL is not applied to open file requests of files inside the device namespace. In other words, even if we specify a strong ACL when creating the device via IoCreateDeviceSecure or other means, then the ACL is not applied to the open file requests. As a result, we don’t really get what we wanted — a call to CreateFile with \Device\testydrv would fail, but a call with “\device\testydrv\anyfile” will succeed because the IoManager doesn’t apply the device ACL to the create request (as it assumes it is a file system driver). For starters, it is considered to be a bug that is worthy of a fix. Also, this will lead non-admin users to try to read/write into the device, perform DeviceIoControl requests and more, which normally is a thing you don’t want non-admin users doing.
You Better User Protection
We can eliminate the threats of unwanted users from straightforwardly interacting with our devices, calling IoCreateDeviceSecure (or WdmlibIoCreateDeviceSecure; it’s the same function) with a Security Descriptor that prevents non-admin users from opening a handle to the device and by using the FILE_DEVICE_SECURE_OPEN value in the creation routine. This will also save us the hassle of declaring the device’s permissions in the registry, as we would need in IoCreateDevice.
RtlInitUnicodeString(&sddlString, L"D:P(A;;GA;;;SY)(A;;GA;;;BA)");
IoCreateDeviceSecure(DriverObject, 65535, &DeviceName, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &sddlString, NULL, &deviceObject);
From a bug hunting standpoint, we should enumerate every possible device in the system, followed by trying to open it with GENERIC_READ | GENERIC_WRITE, which allows us to filter out devices we can’t communicate with. We will revisit this in our second part.
Dispatch Methods
Creating devices is nice and all, but, of course, it isn’t enough for you to communicate with the driver. For that you need IRPs. The driver receives IRPs, I/O Request Packets on behalf of the IoManager for specific triggers. For instance, if an application tries to open a handle to a device, the IoManager will invoke the relevant dispatch method assigned to the driver object. Thus, it allows every driver to support multiple different MajorFunctions for every device it creates. There are around 30 different MajorFunction. If you count the deprecated IRP_MJ_PNP_POWER, each represents a different event. We will focus on only two of these MajorFunction methods and add a short description about the rest, which are the places we should look after while bug hunting.
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = TestyDispatchIoctl;
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = TestyInternalDispatchIoctl;
DriverObject->MajorFunction[IRP_MJ_CREATE] = TestyDispatchCreate;
sDriverObject->MajorFunction[IRP_MJ_CLOSE] = TestyDispatchClose;
DriverObject->MajorFunction[IRP_MJ_READ] = TestyDispatchRead;
DriverObject->MajorFunction[IRP_MJ_WRITE] = TestyDispatchWrite;
DriverObject->MajorFunction[IRP_MJ_CLEANUP] = TestyDispatchCleanup;
Before we dive into the juiciest target, which is the IRP_MJ_DEVICE_CONTROL, we will start with IRP_MJ_CREATE. Every kernel- mode driver must handle IRP_MJ_CREATE in the driver dispatch callback function. The driver must implement IRP_MJ_CREATE because without that, you could not open a handle to the device or a file object.
As you probably guessed, the IRP_MJ_CREATE dispatch routine is invoked when you call NtCreateFile or ZwCreateFile. On most occasions, it will be an empty stub and return a handle with the asked DesiredAccess based on the device’s ACL.
NTSTATUS TestyDispatchCreate(PDEVICE_OBJECT DeviceObject, PIRP irp){
irp->IoStatus.Status = 0;
irp->IoStatus.Information = 0;
IofCompleteRequest(irp, 0);
return 0;
}
However, in some cases, more complex code is involved — even if you met the device’s ACL criteria, you might get a status error like STATUS_INVALID_PARAMETER because you use incorrect parameters in the call to NtCreateFile.
Unfortunately, it indicates you can’t open a device blindly and hope to communicate with the driver via DeviceIoControl; you first need to understand its expected parameters. Usually, the DispatchCreate expects some ExtendedAttributes (can’t use regular CreateFile for that) or specific file name (besides the device name) alongside some other quarks and gluons. Therefore, we must visit the DispatchCreate method
Besides opening a handle, you can also look for vulnerabilities in the DispatchCreate. The more complex the function becomes, the higher the chances of memory allocation and deallocation bugs, especially because the DispatchCreate is not often inspected.
The general approach we take while looking for bugs in drivers is:
- Enumerate every device object
- Try to open it with the most permissive DesiredAccess
- In case of failure, check the status code; if it is not STATUS_ACCESS_DENIED, you can probably still open the handle by doing some manual work and changing some of the parameters
By following this simple algorithm, we will have a list of around 70 devices that we can talk to from a non-admin standpoint. Of course, this number will vary across different Windows machines, since OEM drivers and many types of software also install drivers.
Control the Device with ioctls
While rarely giving you full control over the device/driver, ioctls is de facto the way an application should communicate with a driver. There are two ioctl dispatch routines a driver can create:
// User-Mode application DeviceIoControl, NtDeviceIoControlFile
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = TestyDispatchIoctl;
// Kernel-Mode driver ZwDeviceIoControlFile or the bad IoBuildDeviceIoControlRequest
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = TestyInternalDispatchIoctl;
The only method that matters is TestyDispatchIoctl, since we can’t initiate a call to either IoBuildDeviceIoControlRequest or IIoAllocateIrp with arbitrary parameters, which are the function that trigger the IRP_MJ_INTERNAL_DEVICE_CONTROL major function. If so, please tell me because the internal dispatch method seldom goes through proper testing.
As with any dispatch method of the DriverObject, it receives two parameters from the IoManager.
NTSTATUS TestyDispatchIoctl(PDEVICE_OBJECT DeviceObject, PIRP IRP)
The first is the device object we performed the CreateFile operation on, and the second is a pointer to IRP. The IRP encapsulates the user data and many other things we don’t really care about from a vulnerability research perspective. The main thing we care about here is which parameters are sent from user mode. If we take a look at the signature of NtDeviceIoControlFile, we can guess which fields we care about while looking for bugs in drivers:
BOOL DeviceIoControl(
HANDLE hDevice,
DWORD dwIoControlCode,
LPVOID lpInBuffer,
DWORD nInBufferSize,
LPVOID lpOutBuffer,
DWORD nOutBufferSize,
LPDWORD lpBytesReturned,
LPOVERLAPPED lpOverlapped
);
The main suspects in this method are the input/output buffers, their lengths and the Ioctl code itself. We start with the Ioctl code, which is a 32-bit number that acts as a specifier; it describes how the buffers and the lengths are used/copied to the kernel, the needed DesiredAccess (when you opened a handle to the device) and a function indicator. Let’s see an example:
We can see the ioctl code is 0x1000, which translates to:
- DeviceType: FileDevice_0 → It’s not relevant for us.
- Function: 0 → It’s not relevant for us.
- Method: METHOD_NEITHER → It’s relevant for us, as it describes how IoManager transfers this data to the kernel; more about it shortly
- Access: FILE_ANY_ACCESS →
It’s relevant for us, as it defines the desired access you need to have
over the handle. If you don’t have the correct access, then the
IoManager won’t allow the call to take place and return you
AccessDenied. There are four different values:
- FILE_ANY_ACCESS: You always have a handle to the device, regardless of the DesiredAccess argument.
- FILE_READ_DATA: You requested a handle with GENERIC_READ and got a valid handle
- FILE_WRITE_DATA: You requested a handle with GENERIC_WRITE and got a valid handle FILE_READ_DATA | FILE_WRITE_DATA: Self-explanatory; you need both rights.
Running this DeviceIoControl request on the handle of \Device\VfpExt would cause a BSoD, regardless of your privilege level; we will see why after understanding the field Method.
Method/TransferType, Mother of All Evils
Method/TransferType, Mother of All Evils. This sounds bombastic at first, but unfortunately, it is indeed the case. The method of transport type, the two least significant bits in the ioctl 32 bit-number, indicates the way parameters (buffers and lengths) are referenced in the kernel by the IoManager. As with the Access field, there are four different options:
- (1) METHOD_NEITHER, both bits are on: The IoManager is lazy and does no checks on the buffers and their lengths. The buffers are not copied to the driver and reside in user-mode. Therefore, the user can manipulate the buffers’ lengths and free/allocate their pages at wish, causing many bad things — system crashes and privilege escalation — unless the buffers are probed properly. If you see a driver that does not probe the buffers and uses METHOD_NEITHER, it is safe to assume you have a major security hole in front of you.
- (2) METHOD_BUFFERED, none of the bits are on: The IoManager copies the input/output buffers and their length to the kernel, making it vastly more secure as the user cannot page out the buffers or change their content and lengths on a whim. After that, the input/output buffer pointer is assigned to the IRP.
- (3) METHOD_IN_DIRECT and (4) METHOD_OUT_DIRECT one of the two bits are on: These two are quite similar; the IoManager allocates the input buffer as in METHOD_BUFFERED. For the output buffer, the IoManager probes the buffer and checks if the virtual address is writeable\readable in the current access mode. Then, it locks the memory pages and passes a pointer to the IRP.
Let’s see how a driver might access the user mode buffers and look at a quick vulnerability that demonstrates the issue of not doing proper security checks in drivers.
METHOD_NEITHER: Ioctl code translated to binary ends with 11
Input buffer: irp->Parameters.DeviceIoControl.Type3InputBuffer
Output buffer: irp->UserBuffer
METHOD_DIRECT: Ioctl code translated to binary ends with either 01 or 11
Input buffer: irp->AssociatedIrp.SystemBuffer
Output buffer: irp->MdlAddress
METHOD_BUFFERED: Ioctl code translated to binary ends with 00
Input & Output buffer IRP->AssociatedIrp.SystemBuffer
As a driver can support multiple ioctl codes normally, it has a large switch case for every different ioctl code, affecting where the buffers are stored in memory. In the next section, we will see what happens if we don’t notice.
Blue Screen Goes Boom
In short, our first example of a real bug lies in the Microsoft Azure VFP Extension or vfpext.sys. The story begins in the driver’s ioctl dispatch function. After some variable initialization, it calls a method to validate user-mode parameters followed by some inner logic. We care not.
NTSTATUS __fastcall SxStartDeviceIoControl(PIRP IRP, _WORD *a2, _WORD *a3, _QWORD *a4, int *a5, __int64 a6, __int64 a7)
{
_IO_STACK_LOCATION *CurrentStackLocation; // rdi
bool IsInputBufferBelowLimit; // cf
NTSTATUS result; // eax
BYTE *SystemBuffer; // rbx
int v14; // ecx
__int128 v15; // [rsp+20h] [rbp-28h] BYREF
__int128 v16; // [rsp+30h] [rbp-18h] BYREF
CurrentStackLocation = IRP->Tail.Overlay.CurrentStackLocation;
IRP->IoStatus.Information = 0i64;
IsInputBufferBelowLimit = CurrentStackLocation->Parameters.Create.Options < 0x218; v15 = 0i64; v16 = 0i64; if ( IsInputBufferBelowLimit ) return -1073741811; SystemBuffer = (BYTE *)IRP->AssociatedIrp.SystemBuffer;
result = SxInitUnicodeStringSafe((__int64)&v16, (const wchar_t *)SystemBuffer + 8, 0x100u);
if ( result >= 0 )
{
result = SxInitUnicodeStringSafe((__int64)&v15, (const wchar_t *)SystemBuffer + 0x88, 0x100u);
if ( result >= 0 )
{
*a2 = *((_WORD *)SystemBuffer + 265);
*a3 = *((_WORD *)SystemBuffer + 264);
v14 = CurrentStackLocation->Parameters.Create.Options - 0x218;
*a4 = SystemBuffer + 536;
*a5 = v14;
return SxFindContextByName(&v16, &v15, (PVOID **)a6, (_QWORD *)a7);
}
}
All we really have here is a simple code that does the following:
- Get a pointer to the CurrentStackLocation from the macro IoGetCurrentIrpStackLocation (IRP))
- Verify that buffer length exceeds 0x218
- Create some Unicode strings in a safe way
- Do a look-up operation by calling SxFindContextByName, which we don’t care about
The problem is that in no place does the driver check what the given ioctl IRP->AssociatedIrp is. For example, SystemBuffer is a valid address; it assumes the address of the buffer is valid.
However, looking back at Figure 4, we can assume the driver expects to get an ioctl code with TransferType of either
METHOD_BUFFER or METHOD_IN_DIRECT or METHOD_OUT_DIRECT, as it reads the input buffer from IRP->AssociatedIrp.SystemBuffer.
But, if it is METHOD_NEITHER, then IRP->AssociatedIrp.SystemBuffer means nothing to the IoManager, and it sets it set to zero because it populates IRP->Parameters.DeviceIoControl.Type3InputBuffer instead.
Next, there is a call to SxInitUnicodeStringSafe , which I think is supposed to be a safer version of the kernelic method RtlInitUnicodeString; the second parameter is the SystemBuffer+8 that is the source string.
NTSTATUS __fastcall SxInitUnicodeStringSafe(__int64 Dest, const wchar_t *SystemBuffer, unsigned __int16 a3)
{
__int64 v5; // r11
NTSTATUS result; // eax
size_t v7; // [rsp+38h] [rbp+10h] BYREF
v7 = 0i64;
v5 = Dest;
if ( SystemBuffer )
{
result = RtlStringCbLengthW(SystemBuffer, a3, &v7);
if ( !result )
{
*(_WORD *)v5 = v7;
result = 0;
*(_WORD *)(v5 + 2) = a3;
*(_QWORD *)(v5 + 8) = SystemBuffer;
return result;
}
}
else
{
result = 0;
}
*(_DWORD *)v5 = 0;
*(_QWORD *)(v5 + 8) = 0i64;
return result;
}
SxInitUnicodeStringSafe function decompiled by Ida Pro, receives SystemBuffer, which can point to an invalid memory
So, the address of SystemBuffer address will be 0x10 = (0x0+sizeof(wchar_t *)+8). Hence, on the call to RtlStringCbLengthW, which as the name states, calculates the length, will use the system buffer that points to an invalid address. It contains the code:
for ( i = length; i; --i )
{
if ( !*SystemBuffer )
break;
++SystemBuffer;
}
Here the pointer dereference takes place
When the *SystemBuffer dereferencing happens, you dereferenced an invalid address, and the kernel is not forgiving about the null pointer.
This bug check only requires two lines of code to trigger:
HANDLE hDevice = CreateFile (DEVICE_NAME, NULL, NULL, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
DeviceIoControl(hDevice, 3, NULL, 0x512, NULL, 0x512, NULL, NULL);
In this case, our bug is not exploitable, except by a DoS from a limited user. This bug can also be triggered by a restricted user and in an application sandbox, as well because there is no protection over the device whatsoever. Hence, everyone can get a handle and BSoD. To this day, this vulnerability has not been patched; MSRC response was, “We have completed our investigation and determined that this report is a moderate severity denial of service vulnerability, which unfortunately means that it does not meet our bar for servicing in a security update, and I will be closing this case.” Microsoft’s answer is quite amusing, as it is not just a regular DoS but a system DoS. From a CVSS standpoint, it should be 7.3: https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H . And besides that, the fix is pretty simple; check the ioctl code before using it blindly, which will lead to correct usage of IRP‘s buffers.
Leak Me Some Memory
After having fun with Denial-of-Service attacks, we should proceed to a special, stealthy vulnerability class. Information leakage is the disclosure of kernelic memory to the user-mode. It doesn’t trigger a bug check or any exception, so it is quite difficult to find during the regular pipeline of driver development. You also can’t find it via driver verifier, in contrast to regular memory pool bugs.
Since Windows Vista, Microsoft introduced mitigation called KASLR, making Windows kernel exploitation very challenging. KASLR is the kernelic ASLR, which randomizes drivers, modules, kernelic objects base address on boot. By doing such, you couldn’t abuse arbitrary write primitive as you would in the old days. Back then, you could find an address that would be called by the kernel like HalDispatchTable, followed by placement of a malicious shellcode that would do token stealing that could, for instance, be triggered by a user-mode process. Thus, having arbitrary write was enough for code execution, or you could cancel SMEP for the record.
Nowadays, when the addresses are randomized, one does not know where to assign the shellcode, as the HalDispatchTable is randomized with each boot.
Exploit writers got smarter and pretty quickly understood that you can call NtQuerySystemInformation or EnumDeviceDrivers to get the base address of ntoskrnl. From that, we bypass KASLR, making arbitrary write enough for LPE. But, of course, one can call these APIs only if the controlled process is of medium integrity, which most processes are; browsers are not. Besides that, overwriting the HalDisptachTable with PageEntry corruption is null and void because of new mitigations such as HVCI, which are still not the default on most Windows machines.
Alternatively, one might be able to read data directly from the System process. For example, one might read the SAM file, which is fully loaded into memory. Now, suppose you can extract it from memory. In that case, you can probably crack the hash and find the administrator password, allowing you to achieve full privilege escalation stealthily. Since you don’t really touch the disk, no anti- virus will be triggered.
So what does an info leak look like? It is mostly in the form of getting a kernel pointer of some sensitive kernelic object, but it can also look like disclosing uninitialized kernel memory, like in RtsPer.sys Realtek driver:
DisptachIoctlFDO (PDEVICE_OBJECT Device_Object, IRP *IRP)
{
case 0x2D2324u:
NTStatus2 = rts_ctrl_dump_paras_string(Device_Object, IRP);
...
__int64 __fastcall rts_ctrl_dump_mem_log(PDEVICE_OBJECT Device_Object, PIRP irp)
{
_IO_STACK_LOCATION *CurrentStackLocation; // rbx
PVOID Device_Extension; // rbp
BYTE SystemBuffer; // si
__int64 InputBufferLength; // r9
ULONG OutputBufferLength; // [rsp+50h] [rbp+8h] BYREF
CurrentStackLocation = irp->Tail.Overlay.CurrentStackLocation;
Device_Extension = Device_Object->DeviceExtension;
irp->IoStatus.Information = 0i64;
SystemBuffer = (BYTE *)irp->AssociatedIrp.SystemBuffer;
InputBufferLength = CurrentStackLocation->Parameters.DeviceIoControl.InputBufferLength;
OutputBufferLength = CurrentStackLocation->Parameters.DeviceIoControl.OutputBufferLength;
if ( OutputBufferLength >= 0x107C0 && *(_QWORD *)&SystemBuffer )
{
rts_dump_paras_as_string((__int64)Device_Extension, *(_BYTE **)&SystemBuffer, &OutputBufferLength);// Read&Write memory, disable PCIs
IRP->IoStatus.Information = OutputBufferLength;
return 0i64;
}
else
{
IRP->IoStatus.Information = 0x107C0i64;
return 0x80000005i64;
}
}
}
rts_ctrl_dump_mem_log contains a serious information leakage error
At first glance, the code provided here seems solid; the driver uses METHOD_BUFFERED (because it ends with 00) for transferring data, so user data can’t make page-out its buffers; the buffer lengths are to be trusted (see Figure 11 and above).However, even when using METHOD_BUFFERED, it doesn’t make the code error free; it might lead to a false sense of security.
The easiest way to look for information leakage vulnerabilities is by looking at which data is returned and its length. Since we are dealing with METHOD_BUFFERED, the returned data is via SystemBuffer, and IRP->IoStatus.Information specifies the size (not only for this transfer type). The troubling part is that the IoManager doesn’t initialize the System buffer beyond the copy of the input buffer; in other words, if OutputBufferLength > InputBufferLength, the remainder of the SystemBuffer is uninitialized data. Thus, it is the job of the driver writer to initialize the system buffer and return the correct length of it.
In our case, Figure16, the SystemBuffer, is not being initialized with zeros. We have no checks regarding the input/output buffer lengths, which we have full control over. Also, by looking at the else block, we can inspect a faulty logic:
IRP->IoStatus.Information = 0x107C0i64;
incorrect buffer size assignment
It turns out that by entering the else block, you get back from the kernel 0x107c0 bytes length of kernel data. To be more precise, the IoManager copied the delta between the OutputBufferLength and the InputBufferLength:
OutBufferLength = 0x107c0, InputBufferLength = 1
Therefore, we get back 0x107c0, around 64k of uninitialized data from the memory space of the System process, allowing you to read the content of the SAM file, find the system’s kernel base address and much more. Moreover, you can trigger this behavior as many times as you wish, since it does not raise exceptions.
The exploit code is pretty trivial; the only concern we might have is finding the device name, as it is an autogenerated number (but you can brute-force it as there are only around 0x200 options and similar to how it is shown in Figure 2. Our exploit code consists of the following:
- Open a handle to the device that RtsPer.sys exposes
- Allocate a buffer in the size of 0x107c0
- Call DeviceIoControl
- Write kernel data to a file
A short code to abuse the info leak in RtsPer.sys
This is only one of the many vulnerabilities we discovered in this driver that RealTek recently patched.
As you look at this, it seems that these vulnerabilities are easy to detect and relatively easy to fix — all you need to do is to change the IRP->IoStatus.Information to zero in the else block. Also, you might prevent all of these bugs by altering the device’s permissions, allowing only admin users and above to interact with it. We got CVE-2021-40328 and CVE-2021-40332 for the bugs in this driver.
The third type of bug we would take a look at would lead to full privilege escalation unless it is executed from a low-integrity process . A better and often more useful bug to find in the kernel is arbitrary write. This primitive allows you to write anywhere in the kernel, which presumably would let you overwrite your access token.
If you don’t recall or are new to Windows OS, every process has a kernel counterpart object called an EPROCESS; every EPROCESS object has an access token representing its security context. The System process is de facto the kernel and naturally has the most powerful access token in the operating system. As every EPROCESS resides in the kernel space, we can’t change the access token of the EPROCESS at will; we must do it from the kernel itself. But suppose we have an arbitrary write primitive? In that case, we can change any process’s access token and replace it (kidnapping was the original term) with the System’s process access token. This technique is known as a data-only attack. In contrast to memory corruption techniques, we don’t corrupt any page pool entries, which are susceptible to new mitigations such as kCFG/HVCI/HyperGuard.
Assumptions Are Everything in Bug Hunting
Finding an arbitrary write vulnerability is great but not always sufficient for full local-privilege escalation. As in anything in life, it is based on your assumptions;
If HVCI is on:
- Regardless of your integrity level, arbitrary write in the kernel is not enough for LPE; you also need a read primitive to enable the right permissions in your token.
If HVCI is off:
- Integrity level is Medium (most common); one can invoke EnumDeviceDrivers and NtQuerySystemInformation to get the base address of the kernel, which should allow you with some page entry corruption to overwrite the HalDisptachTable/SMEP. That would be enough for LPE.
- Integrity level is low or untrusted (mostly browsers) — you cannot call the APIs mentioned above; therefore, no kernel base address for you. Must have an additional primitive for LPE.
What does an arbitrary write vulnerability look like? Usually, it involves a dereference of memory and copy operation from a controlled buffer, and it can come in many flavors, from bad memcpy/memmove to just arbitrary pointer dereference. Let’s see a few of the more popular ones:
//the rsp+28h holds the input buffer
mov rax, [rsp+28h+var_4] //destination address
mov rcx, [rsp+28h+var_8] //source source
mov rcx, [rcx]
mov [rax], rcx
a vanilla arbitrary write example found in a driver we can’t comment on
Assuming our driver uses METHOD_NEITHER as the transfer type
and we see the input or output buffer loaded into a register, this is
an arbitrary pointer dereference. In here, both registers RAX and RCX are
pointing to user-mode buffer. Of course, you have full control over
their content, and you have prior knowledge of where they are located in
memory because you have created them. Since we have full control over
the registers, we can write to the memory address pointed by RAX ,a shellcode address pointed by RCX. In other words, we have a write-what-where type of vulnerability or arbitrary write.
Our mindset should be if we have METHOD_NEITHER transfer
type, when the buffers are being used, and in which way. A pattern as
such we have in Figure 19 is a bit rare but still pops from time to
time.
Pure Evil Functions
We can’t talk about arbitrary write vulnerabilities without mentioning one key function that is often the source of it: incorrect usage of either memcpy routine. The memcpy function or the macro that driver developers use, RtlCopyMemory, is unsafe by design. It does not deal with write over bounds or memory overlap; the source or destination is on the same memory. There is a function that deals with memory overlap, which is memmove or the macro RtlMoveMemory. That still doesn’t solve the problem of out-of-bounds write. In addition, every incorrect usage of one of its arguments would likely impose a bug. Please take a look at J00ru’s excellent write-up about this topic, which demonstrates the subtleties in using move/copy functions.
Let’s examine an easy-to-see bug in a driver that shall be nameless:
faulty driver logic, looks bad
The decompiled code shown here is a bit misleading as Ida, which usually makes our lives a lot easier and makes multiple mistakes in distinguishing between structure members of IO_STACK_LOCATION in the case they are unions. That leads to some confusion at first glance for us. Let’s just ignore the bug that the ioctl 0x26DC03 presents, incorrect usage with ProbeForRead, without even using the buffer. Luckily, everyone who is familiar with some kernel internals can see that things look quite odd:
// This is the input buffer length of method Buffered, should be
// CurrentIrpStackLocation->Parameters.DeviceIoControl.InputBufferLength
Length = CurrentIrpStackLocation->Parameters.Create.Options
// This has nothing to do with byte offset, it is the ioctl code, should be
// CurrentIrpStackLocation->Parameters.DeviceIoControl.IoControlCode
LowPart = CurrentIrpStackLocation->Parameters.Read.ByteOffset.LowPart
// v6 is union, {_IRP *MasterIrp;int IrpCount;void *SystemBuffer;}, because we are
// working with buffers, the driver of course users *SystemBuffer which is a structure in our case
v6.MasterIrp = (_IRP *)irp->AssociatedIrp
// This is a length field because it used in memmove
Length_4 = (unsigned int)v6.MasterIrp->MdlAddress
// First two arguments are buffers, destination and source,
// they are two fields in the structure indicated by SystemBuffer
memmove(*(void **)v7.MasterIrp, *(const void **)&v7.MasterIrp->Flags, Length_4a);
correcting the variable names and types
Classic Awful Bugs
To make it look better, we press ALT-Y to choose the proper field of the correct union member of the IO_STACK_LOCATION; let’s see what it looks like:
After the changes, we can see the decompiled output looks like plain C. We have a few calls to memmove, which is the first thing I would recommend doing when looking at a dispatch function. It seems the SystemBuffer is a structure consisting of source, size and destination fields, and they are supplied blindly to memmove method, what I call security at its best. These are the best/worst, depending on the perspectives you can get.
We can see we have three calls to memmove; ioctl 0x26DC04 presents a write everywhere of arbitrary content in the kernel. In contrast, ioctl 0x26FC08 allows to read from the kernel as it would later be assigned to the SystemBuffer (not in Figure 22) and returned to the user. All in all, this driver presents read/write everything functionality, which allows attackers to escalate into a privileged account by the system token. Of course, HVCI is not relevant in this case. The only saving grace we have here is the fact this driver is not accessible from normal user privilege levels, only from admin and above. Therefore, it limits the usefulness for escalation purposes. However, malware might still find this driver helpful. since it is a signed driver with flexible kernelic primitive. That is a great reason not to disclose the driver name in public.
Fixing this driver means rewriting the entire logic of the dispatch routine. Instead of doing that, the vendor changed the ACL of the device to prevent non-admin users from messing with it, and by doing so, it is no longer a security boundary. So no need to fix it