Am 13. August 2024 veröffentlichte das MSTC (Microsoft Security Response Center) CVE-2024-38063, eine kritische Sicherheitslücke im Windows TCP/IP-Stack, die ausgenutzt werden kann, um wichtige Netzwerkfunktionen des Betriebssystems zu gefährden. Die Teilnehmer des OPSWAT Graduate Fellowship Program bieten hier eine gründliche Untersuchung der technischen Details dieser Schwachstelle und ihrer potenziellen Auswirkungen sowie empfohlene Abhilfestrategien für diese Sicherheitslücke.
OPSWAT Fellowship Programm Teilnehmer: Pham Ngoc Thien - Ho Chi Minh Universität für Informationstechnologie
Übersicht
CVE-2024-38063 ist eine kritische Sicherheitslücke im Windows TCP/IP-Stack mit einem CVSS-Score von 9,8, die die Verarbeitung von IPv6-Paketen betrifft. Entfernte Angreifer können diese Sicherheitsanfälligkeit durch einen Integer-Unterlauf bei der Verarbeitung von IPv6-Erweiterungsheadern ausnutzen, um bösartigen Code auszuführen oder einen DoS (Denial of Service) zu verursachen.
Da IPv6 auf den meisten modernen Systemen standardmäßig aktiviert ist, stellt dieser Zero-Click-Fehler ein erhebliches Risiko dar. Daher sind alle ungepatchten Versionen von Windows 10, Windows 11 und Windows Server 2008, 2012, 2016, 2019 und 2022 mit aktiviertem IPv6 anfällig für dieses CVE.
Wichtige Konzepte
Windows TCP/IP-Stapel
Der Windows-TCP/IP-Stack ist eine grundlegende Betriebssystemkomponente, die für die Netzwerkkommunikation über die TCP/IP-Suite (Transmission Control Protocol/Internet Protocol) verantwortlich ist. Er verwaltet alle Netzwerkinteraktionen und erleichtert die Kommunikation zwischen Geräten in lokalen und globalen Netzwerken.
IPv6 und Erweiterungs-Header
IPv6 wurde entwickelt, um die Grenzen von IPv4 zu überwinden. Es führte verschiedene Verbesserungen ein, wie Modularität und Flexibilität durch Erweiterungs-Header. Die Header, die zwischen dem IPv6-Header und der Nutzlast stehen, unterstützen optionale Daten und erweiterte Funktionen.
Zu den wichtigsten IPv6-Erweiterungs-Headern gehören:
- Hop-by-Hop-Optionen (Nächster Header = 0)
- Routing-Kopfzeile (Nächste Kopfzeile = 43)
- Fragment-Kopfzeile (Nächste Kopfzeile = 44)
- Kopfzeile der Zieloptionen (Nächste Kopfzeile = 60)
- Authentifizierungs-Header (AH) (Nächster Header = 51)
- Encapsulating Security Payload (ESP) (Nächster Header = 50)
Jeder Erweiterungs-Header verweist über das Feld Next Header auf den nächsten, wodurch eine sequentielle Kette entsteht. Diese Modularität erhöht die Komplexität des Paketverarbeitungsprozesses und bietet potenzielle Angriffsmöglichkeiten.
Integer-Unterlauf
Ein Integer-Unterlauf tritt auf, wenn eine Berechnung einen kleineren Wert als den minimal darstellbaren Wert für einen Datentyp ergibt. So kann z. B. die Subtraktion eines größeren Wertes von einem kleineren Wert bei einer Ganzzahl ohne Vorzeichen dazu führen, dass das Ergebnis ein sehr großer positiver Wert wird.
Ein Integer-Überlauf tritt auf, wenn der Wert die Höchstgrenze des Datentyps überschreitet und auf den kleinsten darstellbaren Wert "überläuft" (z. B. 0 in einem Bereich von 0-10). Beide Szenarien sind auf die unsachgemäße Behandlung von Randbedingungen bei arithmetischen Operationen zurückzuführen und führen zu schwerwiegenden Sicherheitslücken in Softwaresystemen.
Schwachstellenanalyse
Der Arbeitsablauf der IPv6-Verarbeitung
Nach dem Empfang eines IPv6-Pakets analysiert Windows zunächst den IPv6-Header. Dann prüft die Funktion IppReceiveHeaderBatch den Wert des Feldes Next Header, um den geeigneten Handler für die nachfolgenden Header auszuwählen. Für jeden Erweiterungsheader in der Kette ruft IppReceiveHeaderBatch die entsprechende Routine auf, um diesen spezifischen Header zu verarbeiten.
Trotz des flexiblen und modularen Aufbaus dieses Mechanismus stellt er einen potenziellen Angriffsvektor dar. Bei IPv6 werden fragmentierte Pakete in der Regel am Zielort wieder zusammengesetzt, wo eine Schwachstelle im Prozess des Zusammensetzens von Fragmenten und der Behandlung von Headern besteht.
Ein Angreifer kann eine Fehlverwaltung des Speichers herbeiführen und einen Pufferüberlauf auslösen, indem er zahlreiche missgebildete Pakete mit manipulierten Erweiterungs-Headern sendet. Dadurch können überschüssige Daten unbeabsichtigte Speicherbereiche überschreiben, was möglicherweise die Ausführung von beliebigem Code ermöglicht. Diese Schwachstelle wird als CVE-2024-38063 identifiziert.
Kritischer Fehler im Windows TCP/IP-Stack
Microsofts Patch zur Behebung der Sicherheitslücke CVE-2024-38063 wurde von dem Sicherheitsforscher Marcus Hutchins gründlich untersucht. Sein technischer Blog bietet detaillierte Einblicke in die Ursache dieser Sicherheitslücke. Auf der Grundlage seiner Erkenntnisse hat unser Kollege das Problem weiter erforscht, um ein umfassendes Verständnis der Schwachstelle zu erlangen.
Patch-Analyse
Der Patch enthielt eine Aktualisierung der Datei tcpip.sys, einschließlich einer Änderung innerhalb der Funktion Ipv6pProcessOptions. Eine einzeilige Änderung ersetzte einen Aufruf von IppSendErrorList() durch einen Aufruf von IppSendError(), was darauf hindeutet, dass IppSendErrorList() zum CVE beigetragen haben könnte.
Null-Paketgröße
Eine genauere Untersuchung der Funktion IppSendErrorList() ergab, dass sie eine verknüpfte Liste von Paketen verarbeitet, indem sie für jedes Paket die Funktion IppSendError() aufruft. Die Funktion IppSendError() weist fehlerhaften Paketen den Status STATUS_DATA_NOT_ACCEPTED zu. Dann erstellt sie eine ICMP-Fehlermeldung mit Informationen über das problematische Paket und sendet sie zurück. Wenn jedoch IppSendErrorList() mit always_send_icmp = true für mehrere Pakete aufgerufen wird, setzt sie das Feld packet_size für jedes Paket auf Null.
Die Funktion Ipv6pProcessOptions wurde entwickelt, um Erweiterungsheader zu verarbeiten, die Optionswertfelder enthalten, einschließlich der Header Hop-by-Hop Options und Destination Options. Durch das Setzen des Optionstyps auf einen Wert größer als 0x80 kann ein Angreifer einen spezifischen Fehler in der Verarbeitung des Optionsheaders auslösen, der dazu führt, dass always_send_icmp auf true gesetzt wird und folglich die Paketgröße auf null gesetzt wird.
Während ein Paket mit einer Größe von Null normalerweise verworfen wird, kann ein Angreifer das Next-Header-Feld im ursprünglichen IPv6-Paket manipulieren. Durch diese Manipulation können Angreifer die Kontrolle über die Interpretation des Pakets in den nachfolgenden Verarbeitungsstufen erlangen, wodurch eine sofortige Zurückweisung vermieden und eine Möglichkeit zur Ausnutzung geschaffen wird.
Integer-Unterlauf bei der Fragment-Verarbeitung
Durch das Setzen des Feldes Next Header auf 44, das einen Fragment Header anzeigt, wird ein Paket von IPv6-Fragmentierungs- oder Reassemblierungsroutinen behandelt. Wenn das Paket den Fragment-Parser, Ipv6pReceiveFragment(), erreicht, gibt es dies an:
- Die Paketgröße ist Null.
- Der Fragmentkopf zeigt an, dass noch weitere Daten zu verarbeiten sind.
In der Funktion Ipv6pReceiveFragment() wird die Zuweisungsgröße für fragment_size durch Subtraktion von 0x30 (Paketkopflänge) von der Paketgröße ohne jegliche Validierung berechnet. Wenn die Paketgröße Null ist, läuft diese Subtraktion zu wenig, was zu einem großen 16-Bit-Wert führt (etwa 0xFFD0 oder 65488), was den Parser veranlasst, einen übermäßigen Speicher außerhalb der gültigen Grenzen des Pakets zu verarbeiten und zu einer Speicherbeschädigung führt.
Von Unterlauf zu Überlauf und Fehlanpassung bei der Zuteilung
Die Funktion Ipv6pReassemblyTimeout() ist dafür zuständig, unvollständige IPv6-Fragmente nach einer bestimmten Zeit aufzuräumen, wobei 16-Bit-Arithmetik zur Bestimmung von Puffergrößen und Kopiervorgängen verwendet wird. Aufgrund des Unterlaufs im vorherigen Schritt, bei dem die Paketlänge oder die Fragmentgröße 0xFFD0 wird, kommt es bei der Zuweisung zu einem Überlauf.
Die daraus resultierende Berechnung führt dazu, dass das Register auf Null zurückgesetzt wird, was zur Zuweisung von nur 48 Byte Speicher führt. Da jedoch die Menge der kopierten Daten (65.488 Byte von reassembly->payload) nicht dem zugewiesenen Speicher entspricht, kommt es im Kernel-Pool zu einem kontrollierbaren Pufferüberlauf.
Diese Diskrepanz eröffnet Angreifern die Möglichkeit, über ein speziell gestaltetes Paket, das die Schwachstelle in der IPv6-Verarbeitung ausnutzt, bösartigen Code auszuführen.
CVE-2024-38963 Machbarkeitsnachweis
Bei dem Versuch, die Sicherheitslücke CVE-2024-38963 zu reproduzieren, erstellten unsere Mitarbeiter eine Reihe von missgestalteten Paketen, die die Schwachstelle ausnutzen sollten. Dabei gingen sie wie folgt vor:
1. Fälschung von IPv6-Paketen
Fügen Sie einen IPv6-Zieloptions-Erweiterungsheader (Typ 60) nach dem Basis-IPv6-Header ein und betten Sie dann eine ungültige Option ein (z. B. Optionstyp 0x81).
Diese Manipulation zwingt den Windows-Kernel (tcpip.sys), always_send_icmp = true zu setzen, was die Erzeugung von ICMPv6-Fehlern über die Routine IppSendErrorList() auslöst.
2. Erzwingen der Verarbeitung der Netzpufferliste (NBL)
Die Überflutung des Ziels mit schnellen Bursts dieser missgebildeten Pakete erhöhte die Wahrscheinlichkeit, dass der Kernel mehrere Pakete in einer einzigen Net-Buffer List (NBL) zusammenfasst. Wenn zwei oder mehr Pakete gruppiert werden, wird die anfällige IppSendErrorList()-Schleife aktiviert, wodurch die Metadaten DataLength und Offset in den nachfolgenden Fragmenten fälschlicherweise zurückgesetzt werden (die Paketgröße ist nun Null).
3. Einschleusen von fragmentierten IPv6-Paketen
Nach der Übertragung von fehlerhaften Paketen werden fragmentierte IPv6-Pakete gesendet, die Fragment-Erweiterungs-Header enthalten. Diese Fragmente werden unter Verwendung der bereits verfälschten DataLength-Werte verarbeitet.
4. Ausnutzung der Zeitüberschreitung bei der Wiederzusammensetzung
Der Kernel hält Fragmente 60 Sekunden lang zurück (verwaltet von Ipv6pReassemblyTimeout), um das erneute Zusammensetzen von Paketen zu ermöglichen. Während dieser Zeitüberschreitung lösen die beschädigten DataLength-Werte einen Integer-Unterlauf in Ipv6pReceiveFragment aus, was zu einer falsch berechneten (übermäßig großen) Fragmentgröße führt.
5. Auslösen des Heap-Pufferüberlaufs
Der Kernel weist einen Heap-Puffer auf der Grundlage der unterlaufenden Werte zu. Während des Zusammensetzungsprozesses finden zwei verschiedene Berechnungen statt: Eine bestimmt die Größe der Speicherzuweisung (die aufgrund eines 16-Bit-Überlaufs zu klein wird), die andere berechnet die Kopierlänge anhand des großen, unterlaufenen Werts.
Diese Fehlanpassung führt zu einem Out-of-Bounds-Schreiben, was einen Heap-basierten Pufferüberlauf verursacht, der ausgenutzt werden kann, um einen Denial-of-Service (DoS) oder eine Remotecodeausführung auszulösen.
Der Quellcode, der verwendet wird, um dieses CVE für einen Denial-of-Service-Angriff zu reproduzieren:
Wenn diese Sicherheitslücke von einem Angreifer ausgenutzt wird, kann das System des Opfers sofort abstürzen, was zu einem blauen Bildschirm des Todes führt:
Sanierung
Wenn Sie es versäumen, Ihr Betriebssystem regelmäßig zu aktualisieren, ist Ihr Gerät Sicherheitsbedrohungen ausgesetzt, auch solchen, die mit CVEs (Common Vulnerabilities and Exposures) zusammenhängen. Um diese Risiken zu mindern, bietet MetaDefender Endpoint™ robusten Schutz, indem es die Version Ihres Betriebssystems erkennt und auf Schwachstellen prüft, einschließlich bekannter CVEs wie CVE-2024-38063.
MetaDefender Endpoint wurde entwickelt, um Geräte in kritischen IT/OT-Netzwerken vor Bedrohungen durch Peripheriegeräte und Wechselmedien zu schützen. Es stellt sicher, dass Ihr Betriebssystem und die installierten Anwendungen auf dem neuesten Stand sind, markiert veraltete oder gefährdete Versionen und listet Anwendungen mit bekannten Schwachstellen und CVEs zusammen mit empfohlenen Korrekturen auf. Es hilft auch, Geräte vor Risiken durch Wechselmedien zu schützen, indem es den Zugriff auf USB blockiert, bis diese mit mehreren Anti-Malware-Engines gescannt und für sauber befunden werden, während es Deep CDR™ für mehr als 180 Dateitypen durchführt.
Sprechen Sie noch heute mit einem unserer Experten und erfahren Sie, wie MetaDefender Endpoint Ihre Sicherheitslage mit branchenführender Intelligenz verändern kann.
