CVE-2024-36971 — Proof of Concept (Nur Forschung & Analyse)

⚠️ HAFTUNGSAUSSCHLUSS — LESEN SIE VOR VERWENDUNG DIESES REPOSITORY Dieses Repository ist ausschließlich für defensive Forschung, Analyse und verantwortungsvolle Meldung bestimmt. Es enthält eine nicht ausnutzbare Proof-of-Concept-Datei namens CVE-2024-36971 sowie einen öffentlich verfügbaren Android-Kernel-Header-Ausschnitt (sock.h), um den betroffenen Bereich zu veranschaulichen. Es werden kein Exploit-Code, keine Reproduktionsbefehle oder Schritt-für-Schritt-Anleitungen bereitgestellt. Führen Sie keine Dateien aus diesem Repository auf Produktionsgeräten, fremden Systemen oder Netzwerken aus, die Sie nicht kontrollieren. Der Autor lehnt jede Verantwortung für Missbrauch ab.

Inhaltsverzeichnis

Überblick
Repository-Inhalte
Zusammenfassung auf hoher Ebene
Über den enthaltenen sock.h-Ausschnitt
Forschungsumgebung (hohe Ebene, nicht handlungsrelevant)
Beobachtetes Ergebnis (getestetes Gerät)
Verantwortungsvolle Offenlegung & Kontakt
Rechtlicher & ethischer Hinweis

1. Überblick

CVE-2024-36971 ist eine Use-After-Free (UAF)-Sicherheitslücke im Netzwerk-Subsystem des Android-Kernels. Die Ursache ist eine unsichere Reihenfolge von Operationen bei der Handhabung des Ziel-Caches (dst), der vom Socket-Routing verwendet wird (sk->sk_dst_cache), was zu einem hängenden Zeiger führen kann, der von parallelen Codepfaden zugänglich ist. Dieses Repository dokumentiert einen defensiven Forschungs-PoC, der die Auswirkung (Kernel-Instabilität und Datenkorruption) demonstriert, ohne Exploit-Primitive bereitzustellen.

Diese README erklärt, was der PoC demonstriert, warum der enthaltene sock.h relevant ist, und die verantwortungsvollen Einschränkungen für Tests und Weitergabe.

2. Repository-Inhalte

CVE-2024-36971 — PoC-Quelldatei (aus Transparenzgründen im Repository belassen). Nicht zur Ausführung bestimmt; nur zu Archivierungs-/Analysezwecken enthalten.
sock.h — öffentlicher Android-Kernel-Header-Ausschnitt, der die für das Problem relevanten Socket-/Destination-Strukturen und Hilfsfunktionen zeigt.
README.md — diese Datei (Dokumentation und Anleitung).

3. Zusammenfassung auf hoher Ebene (nicht handlungsrelevant)

Ursache: unsachgemäße Reihenfolge von Referenzverwaltung und Freigabe von dst-Objekten im Routing-/Destination-Cache-Codepfad, was eine Use-After-Free (UAF) ermöglicht.
Auslösevektor (hohe Ebene): Ein Netzwerkpfad, der den __dst_negative_advice() / Destination-Cache-Codepfad im Kernel durchläuft, kann die UAF-Bedingung auslösen. Dieses Repository gibt keine Anweisungen zur Auslösung.
Beobachtete Auswirkung: Kernel-Speicherkorruption, Instabilität und in getesteten Fällen Speichermetadaten-Korruption, die zu einem Startzustand mit „Daten korrupt“ (Soft-Brick) führt.
Ausnutzbarkeitsstatus: Der PoC demonstriert die Auswirkung und bestätigt das Vorhandensein eines kritischen Kernel-Bugs. Die in Tests beobachtete Korruption war nicht deterministisch und destruktiv, kein stabiler, zuverlässiger Exploit zur Codeausführung. Die Umwandlung des Bugs in einen zuverlässigen Exploit würde fortgeschrittene Heap-Manipulation und Allokator-Kontrolle erfordern – solche Arbeiten liegen außerhalb des Umfangs dieses Repositorys und werden nicht bereitgestellt.

4. Über den enthaltenen `sock.h`-Ausschnitt

Der sock.h-Header ist ein öffentlich verfügbarer Kernel-Header (aus Android-Kernel-Bäumen), der Folgendes enthält:

Definitionen für struct sock und verwandte Netzwerkstrukturen;
Referenzen auf sk_dst_cache (den Socket-Destination-Cache) und Hilfsfunktionen zum Abrufen/Setzen von Zielreferenzen;
RCU-/Refcount-Zugriffsmuster und die Verwendung von dst_release().

Dieser Ausschnitt wird bereitgestellt, um die genauen Strukturen und Codestellen zu zeigen, die den Kontext von CVE-2024-36971 liefern. Der Header unterstützt die Erklärung in dieser README, indem er die Datenfelder und Funktionen zeigt, deren Reihenfolge oder Synchronisation für die Korrektheit entscheidend ist.

5. Forschungsumgebung (hohe Ebene, nicht handlungsrelevant)

Hinweis: Das Folgende ist eine Liste typischer Fähigkeiten und Werkzeuge, die von Sicherheitsforschern in einem kontrollierten Labor verwendet werden. Sie ist absichtlich nicht handlungsrelevant – keine Befehle, keine Skripte, keine Parameterwerte.

Empfohlene Fähigkeiten für sichere, isolierte Kernel-Forschung:

Ein isoliertes Testnetzwerk oder ein abgeschottetes Labor, um versehentliche Auswirkungen auf fremde Systeme zu vermeiden.
Dedizierte Testhardware, die Ihnen gehört und die Sie vollständig neu flashen/zurücksetzen können (keine Produktions- oder Fremdgeräte verwenden).
Virtualisierung (z. B. QEMU/KVM) zum Erstellen und Debuggen von Kernel-Images in einer kontrollierten Umgebung.
Der Android-Kernel-Quellbaum und eine lokale Build-Umgebung zum Kompilieren instrumentierter/Debug-Kernel und zum Erzeugen von Symboltabellen.
Debug-/Logging-Werkzeuge und Arbeitsabläufe: adb/fastboot für Gerätezugriff, Sammlung von dmesg/last_kmsg sowie Werkzeuge zum Abbilden von Kernel-Adressen auf Quellzeilen (Symboldateien, addr2line usw.).
Kernel-Debugging und Sanitizer (je nach Bedarf) wie KASAN/KMSAN, ftrace und andere Tracing-Einrichtungen, um Speichersicherheitsverletzungen zu erkennen, ohne eine Ausnutzung zu versuchen.
Sichere Artefaktsammlung und -speicherung für Logs, Backtraces und fotografische Beweise.

6. Beobachtetes Ergebnis (getestetes Gerät)

Getestetes Gerät: Nothing Phone (1) – Gerät im Besitz und unter Kontrolle des Forschers. Das Gerät lief mit einer Kernel-Revision, die zum Zeitpunkt des Tests keinen Fix enthielt.
Testkontext: Der PoC wurde aus demselben lokalen Netzwerk wie das Zielgerät in einer isolierten Testumgebung ausgeführt.
Ergebnis: Nach mehrfachem Senden des PoC-Datenverkehrs erlitt das Gerät schwere Kernel-Speicherkorruption. Die Korruption breitete sich auf Speichermetadaten aus, und das Gerät startete mit einem Fehler, der auf „Daten korrupt“ hinwies. Das Gerät musste repariert/neu geflasht werden, um wieder in einen nutzbaren Zustand zu gelangen (Soft-Brick).
Wichtiger Vorbehalt: Dieses Verhalten war destruktiv und nicht deterministisch; der PoC verursachte Korruption und Datenverlust anstelle einer zuverlässigen Codeausführungs-Primitive. Der Forscher stoppte die Tests, nachdem er destruktives Verhalten beobachtet hatte – das Ziel war, die Auswirkung zu verifizieren, nicht einen funktionierenden Exploit zu entwickeln.

7. Verantwortungsvolle Offenlegung & Kontakt

Dieses Projekt folgt den Prinzipien der verantwortungsvollen Offenlegung. Wenn Sie ein Anbieter, Betreuer oder Sicherheitskontakt sind und zusätzliche nicht handlungsrelevante Diagnoseartefakte (vollständige Backtraces, bereinigte Logs oder forensische Dumps) zur Validierung oder Behebung des Problems benötigen, kontaktieren Sie bitte den Repository-Inhaber über einen sicheren Kanal. Bevorzugte Methoden sind:

das Öffnen eines privaten GitHub-Issues mit Angabe eines sicheren Kommunikationskanals oder
direkte Kontaktaufnahme per PGP-verschlüsselter E-Mail (geben Sie Ihren öffentlichen Schlüssel an oder fordern Sie den Schlüssel des Forschers an).

Der Forscher wird mit validierten Anbietern/Betreuern zusammenarbeiten und zusätzliches Diagnosematerial unter sicheren, angemessenen Bedingungen teilen. Reproduzierbare Reproduktionsschritte werden nicht öffentlich veröffentlicht.

8. Rechtlicher & ethischer Hinweis

CVE-2024-36971

Beliebteste