ronf98/cve-2023-21716-pocPreuve de concept pour CVE-2023-21716 Microsoft Word Corruption de tas
En février 2023, Microsoft a corrigé une vulnérabilité critique dans Microsoft Word, identifiée sous le nom de CVE-2023-21716 avec un score CVSS de 9,8, qui pourrait permettre à des attaquants d'exécuter du code à distance sans authentification. Cette vulnérabilité affectait également le volet d'aperçu d'Outlook, ce qui signifie qu'elle pouvait être déclenchée simplement en prévisualisant le fichier. Bien que Microsoft ait publié un correctif et une solution de contournement, ils n'ont pas divulgué les détails du problème. Le 6 mars, le chercheur qui a découvert le bogue (Joshua J. Drake - @jduck) a partagé une preuve de concept (PoC) sur Twitter.
CVE-2023-21716 provient de la manière dont Microsoft Word gère les fichiers Rich Text Format (RTF), en particulier le mot de contrôle \fonttbl, qui définit les polices dans le document en utilisant le format \f. Le \fonttbl à l'intérieur de wwlib.dll se voit allouer un certain espace dans le tas (Heap) (car les allocations de tas sont généralement utilisées pour des données dynamiques, comme l'analyse de grandes structures telles qu'une table de polices, dont la taille peut varier en fonction de l'entrée). Le crash se produit en raison d'un débordement de tampon (buffer overflow) lorsque le nombre de polices dépasse la limite (prouvée par le PoC à 32760). Le dépassement de l'espace de tas alloué entraîne l'écrasement du pointeur d'instruction de retour (RIP), ce qui provoque le crash de l'application.
Les utilisateurs sont vivement encouragés à installer les derniers correctifs de sécurité de Microsoft, car ils ont résolu ce problème. Pour ceux qui ne peuvent pas mettre à niveau, Microsoft a également fourni plusieurs solutions de contournement, disponibles ici : https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21716.
En utilisant WinDbg, nous pouvons examiner de plus près pour comprendre la cause du crash. Voici le processus :
WinDbg s'arrêtera automatiquement lorsque le crash se produira, ce qui nous permettra de l'analyser plus en détail. Pour commencer, nous pouvons taper 'k' pour afficher la pile d'appels :
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 75e57e80 USER32!UserCallWinProcCheckWow+0x33a
1a 012ff6c4 75e57666 USER32!CallWindowProcAorW+0x7f
1b 012ff6dc 7500ae9d USER32!CallWindowProcW+0x1b
.....
.....
Nos deux bibliothèques clés sont wwlib.dll, une bibliothèque centrale de Word gérant le contenu du document comme les polices, le texte et la mise en page, et ntdll.dll, qui gère les tâches système de bas niveau comme la gestion de la mémoire et la gestion des erreurs. Le crash se produit lorsque Word traite un grand nombre de polices à partir du fichier RTF. Lorsque ntdll.dll détecte que Word tente d'accéder ou de libérer une mémoire invalide (probablement corrompue en raison du débordement de polices), il déclenche une erreur de corruption du tas (heap corruption), entraînant le crash.
Pour approfondir, nous pouvons placer un point d'arrêt dans la dernière partie de la bibliothèque wwlib pour voir comment nos polices sont chargées en mémoire, et comprendre ce qui a déclenché le problème :
bc * //delete all other breakpoints
bp wwlib!PTLS7::FsUpdateFinitePage+0x7e26f //create the breakpoint
Nous obtenons maintenant une violation d'accès :
(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
Comme nous avons arrêté le programme plus tôt, au point où wwlib.dll tente d'abord d'accéder ou de modifier une mémoire invalide (dans FsUpdateFinitePage), cela nous permet de voir la violation d'accès initiale (qui cause la corruption de la mémoire), nous donnant la possibilité d'inspecter ce qui a mal tourné avant que l'erreur de corruption du tas ne soit détectée par ntdll.dll.
Pour être plus précis, le programme s'est arrêté en raison d'une violation d'accès (code c0000005) à l'instruction mov word ptr [esi+edx2+4],cx à l'intérieur de la fonction wwlib!PTLS7::FsUpdateFinitePage+0x7635a. Cette erreur indique que Word a tenté d'accéder à un emplacement mémoire invalide, notamment en essayant de stocker une valeur (cx) dans la mémoire à l'emplacement esi+edx2+4.
Si nous examinons plus en détail le registre ESI, nous voyons qu'il contient les données de police :
Chaque valeur 16 bits (deux octets) au format little-endian représente une entrée de police au format \fA;
La dernière valeur représentée dans ESI est f8 7f qui correspond à {\f32760A;} avant d'atteindre la fin (symbolisée par 29-00)
Maintenant que la table de polices est chargée dans l'emplacement mémoire pointé par le registre ESI, avec un si grand nombre de polices traitées, l'emplacement mémoire calculé (esi + edx*2 + 4) dépasse probablement la mémoire allouée pour la table de polices. Cela entraîne une écriture hors limites (out-of-bounds write), provoquant une erreur de violation d'accès. La violation d'accès est détectée par ntdll.dll, qui gère la gestion de la mémoire et le rapport d'erreurs. En conséquence, ntdll.dll invoque des fonctions qui détectent la corruption du tas, ce qui provoque finalement le crash de l'application.