JFrog untersucht CVE 2025 62507 in Redis Streams: Risiko vom Crash bis zur Remote Code Ausführung

CVE 2025 62507 wurde kürzlich mit Redis 8.2.3 behoben und mit einem CVSSv3 Score von 8,8 als schwerwiegend eingestuft. In der Empfehlung heißt es, dass sich durch den XACKDEL Befehl mit vielen IDs ein Stack Buffer Overflow auslösen lässt, der unter Umständen in Remote Code Ausführung münden kann.

Da Stack Overflows in der Praxis häufig als gut ausnutzbar gelten und die Einstufung zugleich nicht als kritisch ausfiel, hat das Security Research Team von JFrog die Schwachstelle weiter untersucht. Ziel war es, die tatsächliche Ausnutzbarkeit von CVE 2025 62507 zu bewerten, zumal bislang weder ein öffentlicher RCE Exploit noch eine technische Diskussion dazu vorlag.

Was XACKDEL in Redis Streams verändert

Redis wird neben dem Datenspeicher häufig auch als Message Broker über Streams genutzt. Nachrichten werden an einen Stream angehängt, an Verbrauchergruppen ausgeliefert und in der Liste der ausstehenden Einträge nachverfolgt, bis sie als verarbeitet bestätigt werden. Das erhöht die Zuverlässigkeit, erfordert aber Bereinigung von Referenzen und Metadaten.

XACKDEL wurde in Redis 8.2 eingeführt, um diese Bereinigung zu vereinfachen. Der Befehl kombiniert Bestätigen wie bei XACK und Löschen wie bei XDEL in einer atomaren Operation und ergänzt Optionen wie KEEPREF, DELREF und ACKED, die die Behandlung von Referenzen und das Entfernen von Metadaten steuern. Die zusätzliche Komplexität vergrößert jedoch die Angriffsfläche.

Ursache und technische Wirkung

XACKDEL akzeptiert eine variable Anzahl von Stream IDs. Die Implementierung analysiert jede ID und speichert sie in einem Array fester Größe namens static_ids auf dem Stack. Jede ID wird intern als streamID Struktur aus zwei 64 Bit Ganzzahlen abgelegt.

Der Fehler: Es wird nicht geprüft, ob die Anzahl der IDs in die Grenzen dieses Arrays passt. Werden zu viele IDs übergeben, schreibt die Funktion über das Ende des Puffers hinaus. Da die IDs vom Angreifer kontrolliert werden, lassen sich dabei auch sensible Stack Inhalte überschreiben, inklusive der Rücksprungadresse.

Der Bericht betont, dass die Kontrolle besonders präzise ist, weil Stream IDs als zwei numerische Werte getrennt durch einen Bindestrich analysiert und direkt in die Struktur geschrieben werden. In der Standardkonfiguration könne die Bedingung laut JFrog mit einem einzigen XACKDEL Befehl aus der Ferne ausgelöst werden. Da Redis standardmäßig keine Authentifizierung erzwingt, entsteht bei erreichbaren Instanzen ein Risiko nicht authentifizierter Remote Code Ausführung.

Vom Absturz zur Kontrolle des Rücksprungs

JFrog leitet aus dem Stack Layout ab, dass static_ids am Offset minus 0x340 liegt und jedes streamID Element 16 Byte umfasst. Daraus folgt, dass die 53. ID die Rücksprungadresse überschreibt. In frühen Tests wurde beobachtet, dass sich der Befehlszeiger auf niedrige Werte ändert, passend zu der beschriebenen Überschreibung durch die finalen Stream ID Werte.

Exploit Kette in der Beschreibung

Der Bericht ordnet die Ausnutzbarkeit in Schutzmechanismen ein. ASLR macht Adressen unvorhersehbar, weshalb für den Proof of Concept ASLR deaktiviert wird. Stack Canaries werden ebenfalls betrachtet. Die aus einem offiziellen Docker Image extrahierte Redis Server Binärdatei sei ohne Stack Canary Schutz kompiliert gewesen, während eine über den Ubuntu Paketmanager installierte Binärdatei Canaries nutzte.

Da NX den Stack als nicht ausführbar markiert, beschreibt der Bericht eine Return Oriented Programming Kette, die mprotect aufruft. Genannt werden ein beobachteter Stack Zeiger bei 0x7fffffffe7d0, Ausrichtung auf 0x7fffffffe000, eine Größe von 0x20000 Byte sowie Rechte zum Lesen, Schreiben und Ausführen. Anschließend werde die Ausführung über ein CALL rsp Gadget in Daten auf dem Stack übertragen. Zur Demonstration nutzt der Bericht eine Reverse Shell, die per Bash zurück zur Docker Host IP 172.17.0.1 auf Port 4444 verbindet. Er erklärt zudem, warum Bash in Bash eingebunden wird, weil /bin/sh in der Umgebung auf dash verweist und dash die Reverse Shell nicht korrekt erzeugte. Ein Netcat Listener auf dem Host nimmt die Verbindung an. Für gehärtete Systeme nennt der Bericht als zusätzliche Voraussetzungen ein Adressleck zur Umgehung von ASLR und gegebenenfalls das Leaken eines Stack Canary.

Fazit

Die Patch Priorität hängt vor allem von der Erreichbarkeit ab. Ist das Überschreiben der Rücksprungadresse möglich, wird die Unterscheidung zwischen „hoch“ und „kritisch“ praktisch weniger relevant. Der Fall zeigt außerdem, wie Funktionserweiterungen die Angriffsfläche vergrößern können. Build und Packaging beeinflussen die Schutzwirkung, wie der Vergleich zwischen Docker Binärdatei und Distribution Installation nahelegt. Ohne erzwungene Authentifizierung und bei erreichbarer Instanz kann ein einzelner manipulierter Befehl ausreichen.

Die komplette Untersuchung des Security Research Teams von JFrog finden Sie hier: http://jfrog.com/blog/exploiting-remote-code-execution-in-redis

Auch spannend:

---

Bild/Quelle: https://depositphotos.com/de/home.html