Mitigazione

Si consiglia vivamente agli utenti di installare le ultime patch di sicurezza di Microsoft, poiché hanno risolto questo problema. Per coloro che non possono effettuare l'aggiornamento, Microsoft ha anche fornito diverse soluzioni alternative, che possono essere trovate qui: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21716.

CVE-2023-21716-POC

Passi per Riprodurre

1. Installa una versione vulnerabile di Microsoft Office.
2. Scarica ed esegui lo script RTF-creator.
3. Se non vuoi ricreare il file, puoi usare questo file malicious.rtf che contiene 32761 font e attiverà il buffer overflow per far crashare il servizio.
4. Invia il file .rtf via email alla vittima; se ha una versione vulnerabile di Office, la vulnerabilità verrà attivata.

Logica di Sfondo

Usando WinDbg, possiamo dare un'occhiata più da vicino per comprendere la causa del crash. Ecco il processo:

1. Avvia Microsoft Word.
2. Apri WinDbg e collegalo al processo WINWORD.
3. Apri il file malicious.rtf con Word.

WinDbg si fermerà automaticamente quando si verifica il crash, permettendoci di analizzarlo ulteriormente. Per iniziare, possiamo digitare 'k' per visualizzare lo stack delle chiamate:

Le nostre due librerie chiave sono wwlib.dll, una libreria core di Word che gestisce il contenuto del documento come font, testo e layout, e ntdll.dll, che gestisce compiti di sistema di basso livello come la gestione della memoria e la gestione degli errori. Il crash si verifica quando Word processa un gran numero di font dal file RTF. Quando ntdll.dll rileva che Word sta cercando di accedere o liberare memoria non valida (probabilmente corrotta a causa del overflow dei font), solleva un errore di corruzione dell'heap, portando al crash.

Per approfondire, possiamo impostare un breakpoint nell'ultima parte della libreria wwlib per vedere come i nostri font vengono caricati nella memoria e capire cosa ha scatenato il problema:

bc * //delete all other breakpoints

bp wwlib!PTLS7::FsUpdateFinitePage+0x7e26f //create the breakpoint

Ora otteniamo una violation di accesso:

Poiché abbiamo fermato il programma prima, nel punto in cui wwlib.dll sta tentando per la prima volta di accedere o modificare memoria non valida (in FsUpdateFinitePage), ci permette di vedere la violation di accesso iniziale (che causa la corruzione della memoria), dandoci la possibilità di ispezionare cosa è andato storto prima che l'errore di corruzione dell'heap venga rilevato da ntdll.dll.

Per essere più precisi, il programma si è fermato a causa di una violation di accesso (codice c0000005) all'istruzione mov word ptr [esi+edx2+4],cx all'interno della funzione wwlib!PTLS7::FsUpdateFinitePage+0x7635a. Questo errore indica che Word ha tentato di accedere a una posizione di memoria non valida, specificamente quando cercava di memorizzare un valore (cx) nella memoria alla posizione esi+edx2+4.

Se osserviamo più a fondo il registro ESI, possiamo vedere che contiene i dati dei font: Ogni valore a 16 bit (due byte) in formato little-endian rappresenta una voce di font nel formato \fA;

L'ultimo valore rappresentato all'interno dell'ESI è f8 7f che corrisponde a {\f32760A;} prima di raggiungere la fine (simbolizzata da 29-00)

Ora che la tabella dei font è caricata nella posizione di memoria puntata dal registro ESI, con un numero così elevato di font in elaborazione, la posizione di memoria calcolata (esi + edx*2 + 4) supera probabilmente la memoria allocata per la tabella dei font. Ciò risulta in una scrittura fuori dai limiti, causando un errore di violation di accesso. La violation di accesso viene rilevata da ntdll.dll, che gestisce la memoria e la segnalazione degli errori. Di conseguenza, ntdll.dll invoca funzioni che rilevano la corruzione dell'heap, portando infine al crash dell'applicazione.