ronf98/cve-2023-21716-pocProof Of Concept for CVE-2023-21716 Microsoft Word Heap Corruption
In February 2023, Microsoft patched a critical vulnerability in Microsoft Word, identified as CVE-2023-21716 with a CVSS score of 9.8, which could allow attackers to execute remote code without authentication. This vulnerability also affected the Outlook Preview Pane, meaning it can be triggered by only previewing the file. While Microsoft released a patch and a workaround, they did not disclose details about the issue. On March 6, the researcher who discovered the bug (Joshua J.Drake - @jduck) shared a proof of concept (PoC) on Twitter.
CVE-2023-21716 stems from how Microsoft Word handles Rich Text Format (RTF) files, particularly the \fonttbl control word, which defines fonts in the document using the \f format. The \fonttbl inside the wwlib.dll, is allocated a certain amount of space inside the Heap (This is because heap allocations are typically used for dynamic data, such as parsing large structures like a font table, where the size may vary depending on the input). The crash occurs due to a buffer overflow when the number of fonts exceeds the limit (proven by the POC to be 32760). Overrunning the allocated heap space leads to overwriting the Return Instruction Pointer (RIP), which causes the application to crash.
Users are strongly encouraged to install the latest security patches from Microsoft, as they have resolved this issue. For those unable to upgrade, Microsoft has also provided several workarounds, which can be found here: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21716.
Using WinDbg, we can take a closer look to understand the cause of the crash. Here’s the process:
WinDbg will automatically break when the crash occurs, allowing us to analyze it further. To start, we can type 'k' to view the call stack:
0:000> k
# ChildEBP RetAddr
00 012f5134 77a5feb5 ntdll!RtlReportCriticalFailure+0x4b
01 012f5170 77a5dda9 ntdll!RtlpReportHeapFailure+0x2f
02 012f5170 77a66220 ntdll!RtlpHpHeapHandleError+0x89
03 012f5188 77a5dab7 ntdll!RtlpLogHeapFailure+0x43
04 012f51ec 779b400d ntdll!RtlpAnalyzeHeapFailure+0x281
05 012f5348 779f806d ntdll!RtlpFreeHeap+0x24d
06 012f53a4 779b3d66 ntdll!RtlpFreeHeapInternal+0x783
07 012f53c4 6ea4aa24 ntdll!RtlFreeHeap+0x46 //The functions shown under ntdll relate to error handeling of the heap corruption
08 012f53d8 6ea4a9cb mso20win32client!Ordinal1068+0xab
09 012f53e8 6ea4a995 mso20win32client!Ordinal1068+0x52
0a 012f53f4 6cccda52 mso20win32client!Ordinal1068+0x1c
0b 012f5410 03657fea mso!Ordinal1387+0x24
0c 012f5424 03990115 wwlib!PTLS7::FsUpdateFinitePage+0x7e26f //wwlib is in charge of handeling the font table
0d 012f5670 034ea593 wwlib!PTLS7::LsDestroyContext+0x245f90
0e 012f6f5c 033a68ef wwlib!PTLS7::FsUpdateBottomlessPage+0x17494
0f 012f7484 035054ed wwlib!PTLS7::LsAssert+0x2bd1c
10 012f888c 03503d3b wwlib!PTLS7::FsUpdateBottomlessPage+0x323ee
11 012f8910 0400be52 wwlib!PTLS7::FsUpdateBottomlessPage+0x30c3c
12 012f9e9c 0390013a wwlib!wdGetApplicationObject+0xdf8a0
13 012faf48 03ebf20e wwlib!PTLS7::LsDestroyContext+0x1b5fb5
14 012faf90 0410ab2a wwlib!DllCanUnloadNow+0xcc314
15 012fcfe0 03752fb4 wwlib!wdGetApplicationObject+0x1de578
16 012ff538 03385b93 wwlib!PTLS7::LsDestroyContext+0x8e2f
17 012ff578 75e6173b wwlib!PTLS7::LsAssert+0xafc0
18 012ff5a4 75e57eaa USER32!_InternalCallWinProc+0x2b
19 012ff68c 75e57666 USER32!UserCallWinProcCheckWow+0x33a
1a 012ff6c4 75e55e8b USER32!CallWindowProcAorW+0x7f
1b 012ff6dc 7500ae9d USER32!CallWindowProcW+0x1b
.....
.....
Our two key libraries are wwlib.dll, a core Word library managing document content like fonts, text, and layout, and ntdll.dll, which handles low-level system tasks like memory management and error handeling. The crash occurs when Word processes a large number of fonts from the RTF file. As ntdll.dll detects that Word is trying to access or free invalid memory (likely corrupted due to the font overflow), it raises a heap corruption error, leading to the crash.
To dive deeper we can place a breakpoint in the last part of the wwlib library to how our fonts are being loaded inside the memory, and understand what triggered the issue:
bc * //delete all other breakpoints
bp wwlib!PTLS7::FsUpdateFinitePage+0x7e26f //create the breakpoint
We now get an access violation:
(ba4.1a14): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=004f1ce4 ebx=00000001 ecx=000004e4 edx=ffff7ffc esi=13474fe8 edi=00008002
eip=02b300d5 esp=004f1c3c ebp=004f1c48 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206
wwlib!PTLS7::FsUpdateFinitePage+0x7635a:
02b300d5 66894c5604 mov word ptr [esi+edx*2+4],cx ds:002b:13464fe4=???? //The break is happening here
Since we stopped the program earlier, at the point where wwlib.dll is first trying to access or modify invalid memory (in FsUpdateFinitePage), it lets us see the initial access violation (which causes the memory corruption), giving you us chance to inspect what went wrong before the heap corruption error is detected by ntdll.dll.
To be more precise the program stopped due to an access violation (code c0000005) at the instruction mov word ptr [esi+edx2+4],cx inside the wwlib!PTLS7::FsUpdateFinitePage+0x7635a function. This error indicates that Word tried to access an invalid memory location, specifically when trying to store a value (cx) into memory at the location esi+edx2+4.
If we look further into the ESI register, we can see that it holds the font data:
Each 16-bit value (two bytes) in little-endian format represents a font entry in the format \fA;
The last value represented inside the ESI is f8 7f which corresponds to {\f32760A;} before we reach the ending (symbolized by 29-00)
