Behebung

Benutzer werden dringend aufgefordert, die neuesten Sicherheitspatches von Microsoft zu installieren, da diese das Problem behoben haben. Für diejenigen, die nicht aktualisieren können, hat Microsoft auch mehrere Problemumgehungen bereitgestellt, die hier zu finden sind: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21716.

CVE-2023-21716-POC

Schritte zur Reproduktion

1. Installieren Sie eine anfällige Version von Microsoft Office.
2. Laden Sie das Skript RTF-creator herunter und führen Sie es aus.
3. Wenn Sie die Datei nicht neu erstellen möchten, können Sie stattdessen diese Datei malicious.rtf verwenden, die 32761 Schriftarten enthält und den Pufferüberlauf auslöst, um den Dienst zum Absturz zu bringen.
4. Senden Sie die .rtf-Datei per E-Mail an das Opfer. Wenn es eine anfällige Version von Office hat, wird die Sicherheitslücke ausgelöst.

Hintergrundlogik

Mit WinDbg können wir einen genaueren Blick darauf werfen, um die Ursache des Absturzes zu verstehen. Hier ist der Ablauf:

1. Starten Sie Microsoft Word.
2. Öffnen Sie WinDbg und hängen Sie es an den WINWORD-Prozess an.
3. Öffnen Sie die Datei malicious.rtf mit Word.

WinDbg wird automatisch anhalten, wenn der Absturz auftritt, sodass wir ihn weiter analysieren können. Zunächst können wir 'k' eingeben, um den Call Stack anzuzeigen:

Unsere beiden Schlüsselbibliotheken sind wwlib.dll, eine zentrale Word-Bibliothek, die Dokumentinhalte wie Schriftarten, Text und Layout verwaltet, und ntdll.dll, die systemnahe Aufgaben wie Speicherverwaltung und Fehlerbehandlung übernimmt. Der Absturz tritt auf, wenn Word eine große Anzahl von Schriftarten aus der RTF-Datei verarbeitet. Wenn ntdll.dll erkennt, dass Word versucht, auf ungültigen Speicher zuzugreifen oder ihn freizugeben (wahrscheinlich aufgrund des Schriftartenüberlaufs korrupt), löst es einen Heap-Korruptionsfehler aus, der zum Absturz führt.

Um tiefer zu graben, können wir einen Breakpoint im letzten Teil der wwlib-Bibliothek setzen, um zu sehen, wie unsere Schriftarten in den Speicher geladen werden, und zu verstehen, was das Problem ausgelöst hat:

bc * //alle anderen Breakpoints löschen

bp wwlib!PTLS7::FsUpdateFinitePage+0x7e26f //Breakpoint setzen

Wir erhalten nun eine Zugriffsverletzung:

Da wir das Programm früher angehalten haben, an dem Punkt, an dem wwlib.dll zum ersten Mal versucht, auf ungültigen Speicher zuzugreifen oder diesen zu ändern (in FsUpdateFinitePage), können wir die anfängliche Zugriffsverletzung sehen (die die Speicherkorruption verursacht), was uns die Möglichkeit gibt, zu untersuchen, was schiefgelaufen ist, bevor der Heap-Korruptionsfehler von ntdll.dll erkannt wird.

Genauer gesagt, das Programm wurde aufgrund einer Zugriffsverletzung (Code c0000005) an der Instruktion mov word ptr [esi+edx2+4],cx innerhalb der Funktion wwlib!PTLS7::FsUpdateFinitePage+0x7635a angehalten. Dieser Fehler zeigt an, dass Word versucht hat, auf eine ungültige Speicheradresse zuzugreifen, insbesondere beim Versuch, einen Wert (cx) in den Speicher an der Adresse esi+edx2+4 zu schreiben.

Wenn wir uns das ESI-Register genauer ansehen, können wir sehen, dass es die Schriftartendaten enthält: Jeder 16-Bit-Wert (zwei Bytes) im Little-Endian-Format repräsentiert einen Schriftarteintrag im Format \fA;

Der letzte Wert, der im ESI dargestellt wird, ist f8 7f, was {\f32760A;} entspricht, bevor wir zum Ende gelangen (symbolisiert durch 29-00)

Nachdem nun die Schriftartentabelle in den Speicherbereich geladen wurde, auf den das ESI-Register zeigt, wird bei einer so großen Anzahl verarbeiteter Schriftarten die berechnete Speicheradresse (esi + edx*2 + 4) wahrscheinlich den für die Schriftartentabelle zugewiesenen Speicher überschreiten. Dies führt zu einem Schreibzugriff außerhalb der Grenzen, was einen Zugriffsverletzungsfehler verursacht. Die Zugriffsverletzung wird von ntdll.dll erkannt, die die Speicherverwaltung und Fehlerberichterstattung übernimmt. Infolgedessen ruft ntdll.dll Funktionen auf, die Heap-Korruption erkennen, was letztendlich zum Absturz der Anwendung führt.