captain-woof/cve-2026-25243Stable POC für CVE-2026-25243 (Redis RESTORE double-free -> Remote Code Execution)
Verifiziert gegen Rocky Linux 8.10, aarch64, Redis 8.6.2, jemalloc 5.3.0.
Referenz: https://www.zeroday.cloud/blog/redis-cve-2026-25243-deep-dive
TLDR; Stabiler Exploit, funktioniert gegen eine Vielzahl von OS-Distributionen und Architekturen.
Was ist das? Eine Speicherkorruptions-Schwachstelle in Redis, die es einem authentifizierten Angreifer ermöglicht, beliebige Befehle als Redis-Benutzer auszuführen. Der Angriff ist real existent und erfordert nur einen einzigen RESTORE-Befehl – eine normale Redis-Operation, nicht nur für Administratoren. Dieser Exploit demonstriert vollständige RCE in unter einer Sekunde.
Auswirkungen? Jeder authentifizierte Redis-Client kann ihn auslösen, und der Schaden ist total: beliebige Codeausführung im Redis-Prozess (der in Containern oft als root läuft). Es gibt keine Möglichkeit der Abschwächung, ohne Redis selbst zu patchen.
Wie funktioniert es auf einen Blick? Redis verfügt über eine Serialisierungsfunktion (RESTORE), die einen Binärdaten-Blob nimmt und ihn als Redis-Objekt rekonstruiert. Der Code, der das Format des Blobs validiert, und der Code, der es deserialisiert, sind sich uneinig, wie bestimmte Sequenzen zu parsen sind – ein Fehler, den der Angreifer ausnutzt, um den Heap zu korrumpieren. Sobald der Heap korrumpiert ist, erlangt der Angreifer die Fähigkeit, beliebige Speicheradressen im Redis-Prozess zu lesen und zu schreiben, und kapert von dort den internen Zustand des Servers, um einen Shell-Befehl auszuführen.
Die eigentliche Exploit-Technik: Dies ist kein einfacher Absturz. Es ist eine Heap-Exploitation-Kette: korrumpieren → überlappen → beliebiges R/W → Informationsleck → server-Struktur finden → Funktionszeiger kapern → RCE. Der Exploit läuft in 9 Stufen ab und erfordert das Leaken mehrerer Adressen zur Laufzeit, das Parsen binärer Strukturen und das Erkennen von Speicher-Aliasing. Was ihn über Architekturen hinweg (x86-64, aarch64 usw.) funktionieren lässt, ist, dass alle Adressen vom Ziel selbst geleakt werden, nicht angenommen.
CVE-2026-25243 ist ein Paar von Double-Free-Fehlern, die über einen einzigen authentifizierten RESTORE-Befehl erreichbar sind. RESTORE key ttl <serialized-value> deserialisiert einen vom Angreifer kontrollierten RDB-Blob; beide Fehler liegen in der Lücke zwischen dem Validator, der den Blob prüft, und dem Konverter, der ihn materialisiert.
Fehler 1 — Legacy-Zipmap-Konvertierung (CWE-415, der Pfad, den dieser Exploit nutzt). Der Zipmap-Validator (zipmapValidateIntegrity()) und der Konverter (zipmapNext()) sind sich uneinig über eine redundante Längenkodierung. Die kleine Länge 4 kann legal in der langen Fünf-Byte-Form FE 04 00 00 00 geschrieben werden. Der Validator verbraucht eine Anzahl von Bytes, der Konverter eine andere — eine 4-Byte-Parsing-Desynchronisation. Der Konverter durchläuft daher eine andere Struktur als die validierte, lpSafeToAdd() schlägt fehl, nachdem das Feld bereits in das Wörterbuch eingefügt wurde, und der Bereinigungspfad gibt das Feld zweimal frei: einmal über dictRelease() und erneut über sdsfree().
Fehler 2 — Laden der Stream-Consumer-PEL (CWE-415). In rdbLoadStreamConsumersGroup() führt eine Consumer-PEL mit einer doppelten Eintrags-ID dazu, dass der zweite raxTryInsert()-Aufruf fehlschlägt, was streamFreeNACK() auf eine streamNACK aufruft, die sich noch im Besitz der globalen PEL der Gruppe befindet. Zweimal freigegeben. (Auswählbar mit --vuln-type stream.)
Jeder der beiden Fehler verschafft dem Angreifer einen Speicherblock, der gleichzeitig frei und referenziert ist — der klassische Ausgangspunkt für einen Heap-Overlap-Exploit.
Auswirkung: Ein authentifizierter Redis-Client (keine Admin-Rechte, RESTORE ist ein normaler Datenbefehl) erlangt beliebige Codeausführung als Redis-Benutzer — root im Standard-Container-Image.
Neun Stufen, von denen jede ein schwächeres Primitive in ein stärkeres verwandelt:
| Stufe | Erlangtes Primitive | Mechanismus |
|---|---|---|
| 0 | Zielprofil | INFO server / INFO memory → Version, Architektur, Distribution, pid, Pfad der ausführbaren Datei, Startzeit, Allokator |
| 1 | Double-Free | fehlerhafte Zipmap (oder Stream) RESTORE |
| 2 | zwei Schlüssel, die sich Speicher teilen | Marker-Keys auf den freigegebenen Block sprühen, Aliasing erkennen, dann den SDS-Header eines Schlüssels über seinen Zwilling überschreiben, um ihn auf ein 1-MB-„memview" aufzublasen |
| 3 | beliebiges R/W | ein INCRBYFLOAT-Objekt im memview finden, dessen ptr-Feld kapern: GETRANGE/SETRANGE auf diesen Schlüssel liest/schreibt nun beliebige Adressen |
| 4 | Image-Pointer | Heap rückwärts nach einem Wert im redis-server-Image durchsuchen |
| 5 | &server | zum ELF-Header hinuntergehen, Programm-Header parsen, das beschreibbare Segment ausgeben, server.pid abgleichen |
| 6 | Payload im Speicher | "/bin/sh", "-c", "<cmd>" plus ein argv-Array in das memview schreiben |
| 7 | gekapertes Struct | server.executable, server.exec_argv und server.enable_debug_cmd überschreiben |
| 8 | RCE | DEBUG CRASH-AND-RECOVER → restartServer() → execve(server.executable, server.exec_argv, environ) |
python3 exploit.py --host 127.0.0.1 --port 6379 \
--password mypassword --cmd 'id > /tmp/pwned123.txt'
Verifizieren:
cat /tmp/pwned123.txt
# uid=0(root) gid=0(root) groups=0(root)
Ausgangspunkt: Der Exploit war nur für x86-64 und scheiterte in Stufe 3 auf dem aarch64-Ziel. Endzustand: vollständige RCE auf aarch64 Rocky Linux 8.10 in unter einer Sekunde, 116 Redis-Befehle.
a) Laufzeit-Fingerprinting des Ziels (neu, Stufe 0). Über das Ziel wird nichts mehr angenommen. INFO server + INFO memory ergeben die Redis-Version, CPU-Architektur (aus der Zeile os:), Distributionsfamilie (abgeleitet aus gcc_version), Allokator und — am wichtigsten — drei Validierungsanker: process_id, executable und die exakte stat_starttime (server_time_usec/1e6 - uptime_in_seconds). Spätere Stufen vergleichen mit diesen Werten, statt zu raten.
b) Architekturunabhängiges Speicherlayout. Die vier fest kodierten x86-64-Konstanten (BINARY_ADDR_MIN/MAX, HEAP_ADDR_MIN/MAX) werden durch eine pro-Architektur-Tabelle (ARCH_PROFILES) ersetzt, die x86_64, aarch64 (sowohl 39- als auch 48-Bit-VA), riscv64, ppc64le und s390x abdeckt, jeweils mit ET_EXEC- und ET_DYN-Platzierungen, plus einem breiten generischen Fallback für alles nicht Aufgeführte. Das war der eigentliche Grund, warum der Exploit auf diesem Ziel scheiterte: Der geleakte Pointer 0x0000ffff8a5fdf32 ist eine völlig gültige aarch64-mmap-Adresse, die die x86-64-Bereichsprüfung zurückwies.
c) Konsensbasierte Leak-Validierung (Stufe 3). Statt sich auf ein hart kodiertes Heap-Fenster zu verlassen, sammelt der Scan nun jedes strukturell gültige 1337.NNNNNN-Objekt im memview und verlangt, dass mindestens zwei davon dieselbe memview-Basisadresse ableiten (ptr - offset_of_value). In der Praxis stimmen 502 Kandidaten überein – ein Beweis, den keine Bereichstabelle liefern kann. Der bestätigte Pointer kalibriert dann das Heap-Fenster zur Laufzeit. Die Formatvalidierung wurde außerdem vor den (round-trip-teuren) Schreibkontrolltest verschoben.