On Exploiting CVE-2021-1648 (splwow64 LPE)
In this post we’ll examine the exploitability of CVE-2021-1648, a privilege escalation bug in splwow64. I actually started writing this post to organize my notes on the bug and subsystem, and was initially skeptical of its exploitability. I went back and forth on the notion, ultimately ditching the bug. Regardless, organizing notes and writing blogs can be a valuable exercise! The vector is useful, seems to have a lot of attack surface, and will likely crop up again unless Microsoft performs a serious exorcism on the entire spooler architecture.
This bug was first detailed by Google Project Zero (GP0) on December 23, 2020[0]. While it’s unclear from the original GP0 description if the bug was discovered in the wild, k0shl later detailed that it was his bug reported to MSRC in July 2020[1] and only just patched in January of 2021[2]. Seems, then, that it was a case of bug collision. The bug is a usermode crash in the splwow64 process, caused by a wild memcpy in one of the LPC endpoints. This could lead to a privilege escalation from a low IL to medium.
This particular vector has a sordid history that’s probably worth briefly detailing. In short, splwow64 is used to host 64-bit usermode printer drivers and implements an LPC endpoint, thus allowing 32-bit processes access to 64-bit printer drivers. This vector was popularized by Kasperksy in their great analysis of Operation Powerfall, an APT they detailed in August of 2020[3]. As part of the chain they analyzed CVE-2020-0986, effectively the same bug as CVE-2021-1648, as noted by GP0. In turn, CVE-2020-0986 is essentially the same bug as another found in the wild, CVE-2019-0880[4]. Each time Microsoft failed to adequately patch the bug, leading to a new variant: first there were no pointer checks, then it was guarded by driver cookies, then offsets. We’ll look at how they finally chose to patch the bug later – for now.
I won’t regurgitate how the LPC interface works; for that, I recommend reading Kaspersky’s Operation Powerfall post[3] as well as the blog by ByteRaptor[4]. Both of these cover the architecture of the vector well enough to understand what’s happening. Instead, we’ll focus on what’s changed since CVE-2020-0986.
To catch you up very briefly, though: splwow64 exposes an LPC endpoint that
any process can connect to and send requests. These requests carry opcodes and
input parameters to a variety of printer functions (OpenPrinter, ClosePrinter,
etc.). These functions occasionally require pointers as input, and thus the
input buffer needs to support those.
As alluded to, Microsoft chose to instead use offsets in the LPC request buffers instead of raw pointers. Since the input/output addresses were to be
used in memcpy’s, they need to be translated back from offsets to absolute addresses. The functions UMPDStringFromPointerOffset, UMPDPointerFromOffset, and UMPDOffsetFromPointer were added to accomodate this need. Here’s UMPDPointerFromOffset:
int64 UMPDPointerFromOffset(unsigned int64 *lpOffset, int64 lpBufStart, unsigned int dwSize)
{
unsigned int64 Offset;
if ( lpOffset && lpBufStart )
{
Offset = *lpOffset;
if ( !*lpOffset )
return 1;
if ( Offset <= 0x7FFFFFFF && Offset + dwSize <= 0x7FFFFFFF )
{
*lpOffset = Offset + lpBufStart;
return 1;
}
}
return 0;
}
So as per the GP0 post, the buffer addresses are indeed restricted to
<=0x7fffffff. Implicit in this is also the fact that our offset is unsigned,
meaning we can only work with positive numbers; therefore, if our target
address is somewhere below our lpBufStart, we’re out of luck.
This new offset strategy kills the previous techniques used to exploit this
vulnerability. Under CVE-2020-0986, they exploited the memcpy by targeting a
global function pointer. When request 0x6A is called, a function
(bLoadSpooler) is used to resolve a dozen or so winspool functions used for
interfacing with printers:
These global variables are “protected” by RtlEncodePointer, as detailed by
Kaspersky[3], but this is relatively trivial to break when executing locally.
Using the memcpy with arbitrary src/dst addresses, they were able to overwrite
the function pointers and replace one with a call to LoadLibrary.
Unfortunately, now that offsets are used, we can no longer target any arbitrary address. Not only are we restricted to 32-bit addresses, but we are also restricted to addresses >= the message buffer and <= 0x7fffffff.
I had a few thoughts/strategies here. My first attempt was to target UMPD
cookies. This was part of a mitigation added after 0986 as again described by
Kaspersky. Essentially, in order to invoke the other functions available to
splwow64, we need to open a handle to a target printer. Doing this, GDI creates
a cookie for us and stores it in an internal linked list. The cookie is created
by LoadUserModePrinterDriverEx and is of type UMPD:
typedef struct _UMPD {
DWORD dwSignature; // data structure signature
struct _UMPD * pNext; // linked list pointer
PDRIVER_INFO_2W pDriverInfo2; // pointer to driver info
HINSTANCE hInst; // instance handle to user-mode printer driver module
DWORD dwFlags; // misc. flags
BOOL bArtificialIncrement; // indicates if the ref cnt has been bumped up to
DWORD dwDriverVersion; // version number of the loaded driver
INT iRefCount; // reference count
struct ProxyPort * pp; // UMPD proxy server
KERNEL_PVOID umpdCookie; // cookie returned back from proxy
PHPRINTERLIST pHandleList; // list of hPrinter's opened on the proxy server
PFN apfn[INDEX_LAST]; // driver function table
} UMPD, *PUMPD;
When a request for a printer action comes in, GDI will check if the request contains a valid printer handle and a cookie for it exists. Conveniently, there’s a function pointer table at the end of the UMPD structure called by a number of LPC functions. By using the pointer to the head of the cookie list, a global variable, we can inspect the list:
0:006> dq poi(g_ulLastUmpdCookie-8)
00000000`00bce1e0 00000000`fedcba98 00000000`00000000
00000000`00bce1f0 00000000`00bcdee0 00007ffb`64dd0000
00000000`00bce200 00000000`00000001 00000001`00000000
00000000`00bce210 00000000`00000000 00000000`00000001
00000000`00bce220 00000000`00bc8440 00007ffb`64dd2550
00000000`00bce230 00007ffb`64dd2d20 00007ffb`64dd2ac0
00000000`00bce240 00007ffb`64dd2de0 00007ffb`64dd30f0
00000000`00bce250 00000000`00000000
0:006> dps poi(g_ulLastUmpdCookie-8)+(8*9) l5
00000000`00bce228 00007ffb`64dd2550 mxdwdrv!DrvEnablePDEV
00000000`00bce230 00007ffb`64dd2d20 mxdwdrv!DrvCompletePDEV
00000000`00bce238 00007ffb`64dd2ac0 mxdwdrv!DrvDisablePDEV
00000000`00bce240 00007ffb`64dd2de0 mxdwdrv!DrvEnableSurface
00000000`00bce248 00007ffb`64dd30f0 mxdwdrv!DrvDisableSurface
This is the first UMPD cookie entry, and we can see its function table contains 5 entries. Conveniently all of these heap addresses are 32-bit.
Unfortunately, none of these functions are called from splwow64 LPC. When processing the LPC requests, the following check is performed on the received buffer:
(MType = lpMsgBuf[1], MType >= 0x6A) && (MType <= 0x6B || MType - 109 <= 7) )
This effectively limits the functions we can call to 0x6a through 0x74, and the only times the function tables are referenced are prior to 0x6a.
Another strategy I looked at was abusing the fact that request buffers are allocated from the same heap, and thus linear. Essentially, I wanted to see if I could TOCTTOU the buffer by overwriting the memcpy destination after it’s transformed from an offset to an address, but before it’s processed. Since the splwow64 process is disposable and we can crash it as often as we’d like without impacting system stability, it seems possible. After tinkering with heap allocations for awhile, I discovered a helpful primitive.
When a request comes into the LPC server, splwow64 will first allocate a buffer and then copy the request into it:
MessageSize = 0;
if ( *(_WORD *)ProxyMsg == 0x20 && *((_QWORD *)this + 9) )
{
MessageSize = *((_DWORD *)ProxyMsg + 10);
if ( MessageSize - 16 > 0x7FFFFFEF )
goto LABEL_66;
lpMsgBuf = (unsigned int *)operator new[](MessageSize);
}
...
if ( lpMsgBuf )
{
rMessageSize = MessageSize;
memcpy_s(lpMsgBuf, MessageSize, *((const void *const *)ProxyMsg + 6), MessageSize);
...
}
Notice there are effectively no checks on the message size; this gives us the ability to allocate chunks of arbitrary size. What’s more is that once the request has finished processing, the output is copied back to the memory view and the buffer is released. Since the Windows heap aggressively returns free chunks of same sized requests, we can obtain reliable read/write into another message buffer. Here’s the leaked heap address after several runs:
PortView 1008 heap: 0x0000000000DD9E90
PortView 1020 heap: 0x0000000002B43FE0
PortView 1036 heap: 0x0000000000DD9E90
PortView 1048 heap: 0x0000000002B43FE0
PortView 1060 heap: 0x0000000000DD9E90
PortView 1072 heap: 0x0000000002B43FE0
PortView 1084 heap: 0x0000000000DD9E90
PortView 1096 heap: 0x0000000002B43FE0
PortView 1108 heap: 0x0000000000DD9E90
PortView 1120 heap: 0x0000000002B43FE0
PortView 1132 heap: 0x0000000000DD9E90
PortView 1144 heap: 0x0000000002B43FE0
PortView 1156 heap: 0x0000000000DD9E90
PortView 1168 heap: 0x0000000002B43FE0
PortView 1180 heap: 0x0000000000DD9E90
PortView 1192 heap: 0x0000000002B43FE0
PortView 1204 heap: 0x0000000000DD9E90
PortView 1216 heap: 0x0000000002B43FE0
PortView 1228 heap: 0x0000000000DD9E90
PortView 1240 heap: 0x0000000002B43FE0
Since we can only write to addresses ahead of ours, we can use 0xdd9e90 to write into 0x2b43fe0 (offset of 0x1d6a150). Note that these allocations are coming out of the front-end allocator due to their size, but as previously mentioned, we’ve got a lot of control there.
After a few hours and a lot of threads, I abandoned this approach as I was unable to trigger an appropriately timed overwrite. I found a memory leak in the port connection code, but it’s tiny (0x18 bytes) and doesn’t improve the odds, no matter how much pressure I put on the heap. I next attempted to target the message type field; maybe the connection timing was easier to land. Recall that splwow64 restricts the message type we can request. This is because certain message types are considered “privileged”. How privileged, you ask? Well, let’s see what 0x76 does:
case 0x76u:
v3 = *(_QWORD *)(lpMsgBuf + 32);
if ( v3 )
{
memcpy_0(*(void **)(lpMsgBuf + 32), *(const void **)(lpMsgBuf + 24), *(unsigned int *)(lpMsgBuf + 40));
*a2 = v3;
}
A fully controlled memcpy with zero checks on the values passed. If we could gain access to this we could use the old techniques used to exploit this vulnerability.
After rigging up some threads to spray, I quickly identified a crash:
(1b4.1a9c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!RtlpAllocateHeap+0x833:
00007ff9`ab669e83 4d8b4a08 mov r9,qword ptr [r10+8] ds:00000076`00000008=????????????????
0:006> kb
# RetAddr : Args to Child : Call Site
00 00007ff9`ab6673d4 : 00000000`01500000 00000000`00800003 00000000`00002000 00000000`00002010 : ntdll!RtlpAllocateHeap+0x833
01 00007ff9`ab6b76e7 : 00000000`00000000 00000000`012a0180 00000000`00000000 00000000`00000000 : ntdll!RtlpAllocateHeapInternal+0x6d4
02 00007ff9`ab6b75f9 : 00000000`01500000 00000000`00000000 00000000`012a0180 00000000`00000080 : ntdll!RtlpAllocateUserBlockFromHeap+0x63
03 00007ff9`ab667eda : 00000000`00000000 00000000`00000310 00000000`000f0000 00000000`00000001 : ntdll!RtlpAllocateUserBlock+0x111
04 00007ff9`ab666e2c : 00000000`012a0000 00000000`00000000 00000000`00000300 00000000`00000000 : ntdll!RtlpLowFragHeapAllocFromContext+0x88a
05 00007ff9`a9f39d40 : 00000000`00000000 00000000`00000300 00000000`00000000 00007ff9`a9f70000 : ntdll!RtlpAllocateHeapInternal+0x12c
06 00007ff6`faeac57f : 00000000`00000300 00000000`00000000 00000000`01509fd0 00000000`00000000 : msvcrt!malloc+0x70
07 00007ff6`faea7c76 : 00000000`00000300 00000000`01509fd0 00000000`015018e0 00000000`00000000 : splwow64!operator new+0x23
08 00007ff6`faea8ada : 00000000`00000000 00000000`01501678 00000000`0150e340 00000000`0150e4f0 : splwow64!TLPCMgr::ProcessRequest+0x9e
That’s the format of our spray, but you’ll notice it’s crashing during allocation. Basically, the message buffer chunk was freed and we’ve managed to overwrite the freelist chunk’s forward link prior to it being reused. Once our next request comes in, it attempts to allocate a chunk out of this sized bucket and crashes walking the list.
Notably, we can also corrupt a busy chunk’s header, leading to a crash during the free process:
0:006> kb
# RetAddr : Args to Child : Call Site
00 00007ffe`1d5b7e42 : 00000000`00000000 00007ffe`1d6187f0 00000000`00000003 00000000`014d0000 : ntdll!RtlReportCriticalFailure+0x56
01 00007ffe`1d5b812a : 00000000`00000003 00000000`02d7f440 00000000`014d0000 00000000`014d9fc8 : ntdll!RtlpHeapHandleError+0x12
02 00007ffe`1d5bdd61 : 00000000`00000000 00000000`014d0150 00000000`00000000 00000000`014d9fd0 : ntdll!RtlpHpHeapHandleError+0x7a
03 00007ffe`1d555869 : 00000000`014d9fc0 00000000`00000055 00000000`00000000 00007ffe`00000027 : ntdll!RtlpLogHeapFailure+0x45
04 00007ffe`1d4c0df1 : 00000000`014d02e8 00000000`00000055 00000000`00000001 00000000`00000055 : ntdll!RtlpHeapFindListLookupEntry+0x94029
05 00007ffe`1d4c480b : 00000000`014d0000 00000000`014d9fc0 00000000`014d9fc0 00000000`00000080 : ntdll!RtlpFindEntry+0x4d
06 00007ffe`1d4c95c4 : 00000000`014d0000 00000000`014d0000 00000000`014d9fc0 00000000`014d0000 : ntdll!RtlpFreeHeap+0x3bbcd s
07 00007ffe`1d4c5d21 : 00000000`00000000 00000000`014d0000 00000000`00000000 00000000`00000000 : ntdll!RtlpFreeHeapInternal+0x464
08 00007ffe`1cdf9c9c : 00000000`030c1490 00000000`014d9fd0 00000000`014d9fd0 00000000`00000000 : ntdll!RtlFreeHeap+0x51
09 00007ff7`28b8805d : 00000000`030c1490 00000000`014d9fd0 00000000`00000000 00000000`00000000 : msvcrt!free+0x1c
0a 00007ff7`28b88ada : 00000000`00000000 00000000`00000000 00000000`030c0cd0 00000000`030c0d00 : splwow64!TLPCMgr::ProcessRequest+0x485
This is an interesting primitive because it grants us full control over a heap chunk, both free and busy, but unlike the browser world, full of its class objects and vtables, our message buffer is flat, already assumed to be untrustworthy. This means we can’t just overwrite a function pointer or modify an object length. Furthermore, the lifespan of the object is quite short. Once the message has been processed and the response copied back to the shared memory region, the chunk is released.
I spent quite a bit of time digging into public work on NT/LF heap exploitation primitives in modern Windows 10, but came up empty. Most work these days focuses on browser heaps and, typically, abusing object fields to gain code execution or AAR/AAW. @scwuaptx[7] has a great paper on modern heap internals/primitives[6] and an example from a CTF in ‘19[5], but ends up using a FILE object to gain r/w which is unavailable here.
While I wasn’t able to take this to full code execution, I’m fairly confident this is doable provided the right heap primitive comes along. I was able to gain full control over a free and busy chunk with valid headers (leaking the heap encoding cookie), but Microsoft has killed all the public techniques, and I don’t have the motivation to find new ones (for now ;P).
The code is available on Github[8], which is based on the public PoC. It uses my technique described above to leak the heap cookie and smash a free chunk’s flink.
Patch
Microsoft patched this in January, just a few weeks after Project Zero FD’d the bug. They added a variety of things to the function, but the crux of the patch now requires a buffer size which is then used as a bounds check before performing memcpy’s.
GdiPrinterThunk now checks if DisableUmpdBufferSizeCheck is set in HKLM\Software\Microsoft\Windows NT\CurrentVersion\GRE_Initialize. If it’s not, GdiPrinterThunk_Unpatched is used, otherwise, GdiPrinterThunk_Patched. I can only surmise that they didn’t want to break compatibility with…something, and decided to implement a hack while they work on a more complete solution (AppContainer..?). The new GdiPrinterThunk:
int GdiPrinterThunk(int MsgBuf, int MsgBufSize, int MsgOut, unsigned int MsgOutSize)
{
int result;
if ( gbIsUmpdBufferSizeCheckEnabled )
result = GdiPrinterThunk_Patched(MsgBuf, MsgBufSize, (__int64 *)MsgOut, MsgOutSize);
else
result = GdiPrinterThunk_Unpatched(MsgBuf, (__int64 *)rval, rval);
return result;
}
Along with the buf size they now also require the return buffer size and check to ensure it’s sufficiently large enough to hold output (this is supplied by the ProxyMsg in splwow64).
And the specific patch for the 0x6d memcpy:
SrcPtr = **MsgBuf_Off80;
if ( SrcPtr )
{
SizeHigh = SrcPtr[34];
DstPtr = *(void **)(MsgBuf + 88);
dwCopySize = SizeHigh + SrcPtr[35];
if ( DstPtr + dwCopySize <= _BufEnd // ensure we don't write past the end of the MsgBuf
&& (unsigned int)dwCopySize >= SizeHigh // ensure total is at least >= SizeHigh
&& (unsigned int)dwCopySize <= 0x1FFFE ) // sanity check WORD boundary
{
memcpy_0(DstPtr, SrcPtr, v276 + SrcPtr[35]);
}
}
It’s a little funny at first and seems like an incomplete patch, but it’s because Microsoft has removed (or rather, inlined) all of the previous UMPDPointerFromOffset calls. It still exists, but it’s only called from within UMPDStringPointerFromOffset_Patched and now named UMPDPointerFromOffset_Patched. Here’s how they’ve replaced the source offset conversion/check:
MCpySrcPtr = (unsigned __int64 *)(MsgBuf + 80);
if ( MsgBuf == -80 )
goto LABEL_380;
MCpySrc = *MCpySrcPtr;
if ( *MCpySrcPtr )
{
// check if the offset is less than the MsgBufSize and if it's at least 8 bytes past the src pointer struct (contains size words)
if ( MCpySrc > (unsigned int)_MsgBufSize || (unsigned int)_MsgBufSize - MCpySrc < 8 )
goto LABEL_380;
// transform offset to pointer
*MCpySrcPtr = MCpySrc + MsgBuf;
}
It seems messier this way, but is probably just compiler optimization. MCpySrc is the address of the source struct, which is:
typedef struct SrcPtr {
DWORD offset;
WORD SizeHigh;
WORD SizeLow;
};
Size is likely split out for additional functionality in other LPC functions, but I didn’t bother figuring out why. The destination offset/pointer is resolved in a similar fashion.
Funny enough, the GdiPrinterThunk_Unpatched really is unpatched; the vulnerable memcpy code lives on.
References
[0] https://bugs.chromium.org/p/project-zero/issues/detail?id=2096
[1] https://whereisk0shl.top/post/the_story_of_cve_2021_1648
[2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1648
[3] https://securelist.com/operation-powerfall-cve-2020-0986-and-variants/98329/
[4] https://byteraptors.github.io/windows/exploitation/2020/05/24/sandboxescape.html
[5] https://github.com/scwuaptx/LazyFragmentationHeap/blob/master/LazyFragmentationHeap_slide.pdf
[6] https://www.slideshare.net/AngelBoy1/windows-10-nt-heap-exploitation-english-version
[7] https://twitter.com/scwuaptx
[8] https://github.com/hatRiot/bugs/tree/master/cve20211648