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).

Anmerkungen

• Das Obige ist nur eine Strategie, um das durch das Auslösen der Schwachstelle entstandene Problem auszunutzen. Ich habe diese Strategie verwendet, weil sie ziemlich unkompliziert war und ich keine Zeit damit verschwenden wollte, andere Möglichkeiten zu untersuchen. Ich wäre nicht überrascht, wenn andere Leute bald mit viel eleganteren Strategien aufwarten.
• Was die Schwachstelle erfordert:
  • IPv6-Fähigkeit auf dem Zielsystem, Fähigkeit, Pakete zu empfangen (vor der Firewall)
  • Fähigkeit, das Zielsystem dazu zu bringen, die gesendeten Pakete bis zu einem gewissen Grad zu koaleszieren. Manche Adapter-/Treiber-Kombinationen tun dies sehr gerne, während andere eher zögerlich zu sein scheinen. Es könnte Tricks oder spezielle Paketketten geben, mit denen man Windows-RSC dazu bringen kann, Pakete unabhängig vom Adapter oder der Netzwerkgesundheit zu koaleszieren, aber ich habe dafür keine Belege.
• Was die Schwachstelle nicht erfordert:
  • Das Spammen von Paketen; der PoC tut dies nur, um die Wahrscheinlichkeit der Koaleszierung zu erhöhen und als Demonstration mehrere Korruptionen auszulösen.
  • Hohe Lastsituationen auf dem Zielsystem, da Koaleszierung in vielen verschiedenen Situationen auftreten kann.
  • Bestimmte Einstellungen auf dem Zielsystem, außer dass IPv6 aktiviert ist.
  • (Höchstwahrscheinlich) Eine Minute Warten, um die Korruption auszulösen; ich habe diese Strategie des Missbrauchs der Schwachstelle nur verwendet, weil sie am einfachsten war. Es besteht eine sehr reale Chance, dass die durch die Schwachstelle verursachte Problemsituation auf direkterem Wege ausgenutzt werden könnte.
  • (Höchstwahrscheinlich) Unicast-Pakete; ich verwende sie, weil der von uns genutzte Codepfad in Ipv6pReassemblyTimeout erfordert, dass das ursprüngliche Fragment-Paket als Unicast gesendet wird.

Fehlerbehebung

Wenn es nicht funktioniert, könnte das daran liegen:

• Das Zielsystem ist über IPv6 nicht erreichbar:
  • Deaktiviere die Windows-Firewall
  • ping -6 {ipv6_address} vom Host-PC aus
  • Stelle sicher, dass du eine Antwort erhältst
  • Aktiviere die Firewall wieder
• Das Zielsystem empfängt keine Pakete
  • Installiere Wireshark auf dem Zielsystem und prüfe, ob die vom Skript gesendeten Pakete ankommen
• scapy meldet "Mac address to reach destination not found. Using broadcast."
  • Du musst die MAC-Adresse des Zielsystems herausfinden
  • Das geht, indem du den obigen Ping-Befehl ausführst und die Antwort in Wireshark prüfst (Feld der Ethernet-Quelladresse)
  • Du kannst auch scapy verwenden: Ether(raw(sr1(IPv6(dst={your_dest_ip})/ICMPv6EchoRequest()))).src, aber das funktioniert manchmal nicht
  • Sobald du die MAC-Adresse hast, trage sie in das mac_addr-Feld im Skript ein und führe das Skript aus
• Pakete werden auf dem Zielsystem nicht koalesziert
  • Je nach Netzwerkadapter/-treiber kann es schwierig sein, Windows dazu zu bringen, Pakete zu koaleszieren, ohne auf so etwas wie ein Überfluten des Ziels (ähnlich wie bei einem DDoS) zurückzugreifen.
  • Du kannst versuchen, die Adaptereinstellungen zu ändern, z. B. "Packet Coalescing", "Interrupt Moderation", "Interrupt Moderation Mode", "Recv Segment Coalescing", je nachdem, welche verfügbar sind. Zum Beispiel macht die Einstellung "Interrupt Moderation Mode" auf "Extreme" auf meinem dedizierten Server die Schwachstelle reproduzierbar.
• Wenn alles andere fehlschlägt, kannst du einen Kernel-Debugger anhängen und ein paar Dinge prüfen:
  • Wird tcpip!Ipv6pReceiveDestinationOptions -> tcpip!Ipv6pProcessOptions -> tcpip!IppSendErrorList erreicht?
  • Setze einen Breakpoint auf tcpip!Ipv6pProcessOptions und prüfe, ob [rcx] die ganze Zeit null ist. Falls ja, werden die Pakete aus irgendeinem Grund nicht koalesziert.
  • Setze einen Breakpoint auf tcpip!Ipv6pReceiveFragment und prüfe, ob [rcx+0x30] gleich null ist. Falls nicht, konnte die Schwachstelle aus irgendeinem Grund nicht ausgelöst werden.