Dies ist ein (eher unzuverlässiger) PoC für CVE-2024-38063, eine RCE in tcpip.sys, die am 13. August 2024 gepatcht wurde. Ich habe diese Schwachstelle nicht gefunden und gemeldet, das war Wei.

Anforderungen

pip3 install scapy

Verwendung

Ändere die Felder im Skript:

• iface <- Wenn du mehrere Adapter hast, musst du auswählen, mit welchem die Pakete gesendet werden sollen, z. B. "eth0" unter Linux oder "Hyper-V Virtual Ethernet Adapter" unter Windows. Wenn du dein Standard-Interface verwenden möchtest, lass es leer.
• ip_addr <- IP-Adresse des Zielsystems (IPv6)
• num_tries & num_batches <- Wie viele verschiedene Paket-Batches gesendet werden sollen. Mehr davon = mehr Heap-Korruptionen verursacht + höhere Chance, die Schwachstelle auszulösen.
• mac_addr <- Leer lassen, außer scapy meldet, dass es die MAC-Adresse nicht finden kann. Siehe unten unter Fehlerbehebung.

Führe das Skript aus:

python3 cve-2024-38063.py

Der einfachste Weg, die Schwachstelle zu reproduzieren, ist die Verwendung von bcdedit /set debug on auf dem Zielsystem und ein Neustart des Rechners/der VM. Dadurch wird kdnic.sys zum Standard-Netzwerkadapter-Treiber, der Pakete sehr gerne koalesziert. Wenn du versuchst, die Schwachstelle in einem anderen Setup zu reproduzieren, musst du das System in einen Zustand bringen, in dem es die von dir gesendeten Pakete koalesziert. Weitere Details findest du im Abschnitt Fehlerbehebung unten.

Demo

cve-2024-38063.webm

Grobe Ursachenanalyse (RCA)

Du kannst diese großartige Analyse der Schwachstelle von Marcus lesen, wenn du an den technischen Details interessiert bist. Die Details, die ich unten geschrieben habe, sollen eher als Zusammenfassung dienen denn als ernsthafte technische Analyse.

• In bestimmten Situationen koalesziert Windows mehrere IP-Pakete und verarbeitet sie stapelweise. Es verarbeitet zuerst die Extension Headers in jedem Paket und fährt erst danach mit der Verarbeitung der Daten in jedem Paket fort.
• Während der Verarbeitung der Extension Headers werden die Paketobjekte dieser koaleszierten Pakete in einer verknüpften Liste miteinander verbunden. Jedes Paketobjekt enthält ein NET_BUFFER -Objekt, das die gepufferten Paketdaten enthält. Bei Offset 0x30 gibt es außerdem ein Current-Offset-Feld, das angibt, wie weit das Paket bereits geparst wurde. In dieser Phase beträgt der Offset-Wert in der Regel 0x28, was bedeutet, dass der IPv6-Header geparst wurde, aber sonst nichts.
• Wenn bei der Verarbeitung des "Destination Options"-Extension-Headers in tcpip!Ipv6pReceiveDestinationOptions ein Parsing-Fehler auftritt, führt dies dazu, dass tcpip!IppSendErrorList aufgerufen wird. Diese Funktion ruft tcpip!IppSendError für jedes Paketobjekt in der verknüpften Liste auf (beginnend mit dem aktuellen).
• Unter bestimmten Bedingungen (z. B. wenn das Paket Unicast ist) hat tcpip!IppSendError Nebenwirkungen. Es setzt die gepufferten Paketdaten auf den Anfang zurück und setzt das Current-Offset-Feld auf null.
• Allerdings wird in dieser gesamten Ereigniskette nur das erste Paket als fehlerhaft markiert (Offset 0x8C). Das bedeutet, dass der Treiber weiterhin die Extension Headers anderer Pakete in der verknüpften Liste parst, selbst wenn sie in IppSendError "zurückgesetzt" wurden.
• Die Verarbeitung dieser zurückgesetzten Pakete erfolgt dann mit unerwarteten Daten: Die gepufferten Paketdaten zeigen auf den Anfang des Pakets (d. h. den IPv6-Header) statt auf die Extension Headers, und der Wert des Offset-Felds ist null statt 0x28.

Strategie

• Um die Schwachstelle auszunutzen, verwenden wir Ipv6pReceiveFragment. Die Funktion parst den Fragment-Extension-Header und geht bei der Berechnung der Länge der Nicht-Header-Daten im Paket davon aus, dass das Offset-Feld des Pakets mindestens 0x28 beträgt, indem sie 0x30 vom aktuellen Offset-Wert subtrahiert. Dieser Wert wird dann im Reassembly-Objekt gespeichert, dessen Zweck es ist, das fragmentierte Paket wieder zusammenzusetzen.
• In unserem Fall wird die Funktion für ein Paket aufgerufen, das von IppSendError zurückgesetzt wurde. Der Offset-Wert ist null und wird an einer früheren Stelle in Ipv6pReceiveFragment auf 8 erhöht. Bei der Berechnung der Größe der Nicht-Header-Daten kommt es zu einem Unterlauf, und der Wert entspricht 0xffd8 (die Subtraktion erfolgt in 16 Bit).
• Der Längenwert wird später nur an zwei Stellen verwendet:
  • Ipv6pReassembleDatagram, wo er zur Berechnung der Länge eines Ausgabepuffers für das reassemblierte Paket verwendet wird. Alle Berechnungen erfolgen jedoch in 32 Bit, und es gibt eine Plausibilitätsprüfung, dass die Gesamtlänge 0xFFFF nicht überschreitet, was in diesem Fall geschieht.
  • Ipv6pReassemblyTimeout, wo er ebenfalls auf dieselbe Weise verwendet wird. Hier erfolgen die Berechnungen jedoch in 16 Bit, und es kommt zu einem Integer-Überlauf. Dies führt später zu einem Pufferüberlauf, wenn Daten in den Puffer kopiert werden.

Um Ipv6pReassemblyTimeout auszulösen, muss der Absender des Fragments 1 Minute lang inaktiv sein. Unsere Strategie ist dann:

• Sende fehlerhafte Destination Options, um IppSendError auszulösen, gefolgt von einem Fragment-Paket
• Hoffe, dass die beiden Pakete koalesziert werden und dass das Objekt des zweiten Pakets seine Daten und seinen Offset zurücksetzt
• Verursache den Unterlauf in Ipv6pReceiveFragment und erstelle ein neues Reassembly-Objekt mit einer Fragment-Datenlänge, die ein hoher 16-Bit-Wert ist
• Warte 1 Minute, ohne weitere Pakete zu senden, damit Ipv6pReassemblyTimeout ausgelöst wird.
• Verursache einen Integer-Überlauf bei der Berechnung der Puffergröße in Ipv6pReassemblyTimeout und löse einen Heap-basierten Pufferüberlauf aus.

Die Pakete im Skript werden gespammt, damit die Wahrscheinlichkeit höher ist, dass sie koalesziert werden. Die Haupt-Payload ist ziemlich einfach:

• IPv6-Paket mit einem "Destination Options"-Extension-Header mit fehlerhaften Optionsdaten, die einen Parsing-Fehler auslösen
• IPv6-Fragment #1, von dem wir hoffen, dass es an das erste Paket angehängt wird
• IPv6-Fragment #2 (gleiche ID), das möglicherweise ebenfalls an die ersten beiden angehängt wird, dessen Hauptzweck es aber ist, das zweite Fragment zu vervollständigen, damit im Fall einer normalen Verarbeitung keine Fehler ausgelöst werden

Wir setzen außerdem die Hop-Limit- und Flow-Label-Felder im IPv6-Header manuell. Erinnere dich: Die gepufferten Paketdaten werden aufgrund der Schwachstelle zurückgesetzt. Das bedeutet, dass bei der Verarbeitung des Fragment-Pakets der IPv6-Header als Fragment-Header-Daten interpretiert wird. Das Hop-Limit-Feld im IPv6-Header wird als eines der Bits des ID-Felds im Fragment-Header interpretiert. Indem wir es ändern, stellen wir sicher, dass wir die Schwachstelle für mehrere verschiedene Fragmente auslösen und mehrere verschiedene Korruptionen verursachen, was die Wahrscheinlichkeit eines Absturzes erhöht (schließlich ist es ein PoC). Das Flow-Label-Feld des IP-Headers wird als die Offset- und "More-Indikator"-Felder des Fragment-Headers interpretiert. Indem wir es auf 1 setzen, geben wir an, dass weitere Header folgen (und wir später Ipv6pReassemblyTimeout auslösen können) und dass der Offset null ist (da dies das erste eintreffende Paket mit einer solchen ID ist).