open-flaw/cve-2025-49844Proof-of-Concept-Exploit für CVE-2025-49844, der eine Redis-Heap-Schwachstelle angreift, mit GDB-gestützter Crash-Analyse und Fuzzing-Versuchen, um Codeausführung zu erreichen.
KI-erstellter Revshell-PoC
Ungetestete Vervollständigung des von KI erstellten Redishell-PoC.
Original-PoC:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Koreanisches Puzzleteil:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Später haben wir GDB angeschlossen - uns gelang es, die Basisadresse zu ermitteln und ein paar weitere Dinge herauszufinden, aber vor allem scheint es, dass dies keine einfache Heap-Schwachstelle ist. Egal, was wir versuchten, es war unmöglich, Codeausführung zu erlangen. Absturz? Ja. Befehle? Nein.
Wir sind im Reversing nicht mehr sattelfest, daher können wir uns nicht sicher sein, aber nach allem, was wir über Stunden hinweg mit Hilfe einiger der stärksten KI-Modelle herausgefunden haben, ist es nicht möglich, durch diese Schwachstelle Codeausführung zu erlangen (oder es ist einer von tausend Versuchen, aber das ist reine Spekulation).
Nach zahlreichen Versuchen sind wir bestenfalls immer ungefähr hier gelandet:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Ich bin gespannt darauf, den echten PoC mit Codeausführung zu sehen.
BITTE RICHTIG LESEN: Wir sagten, NACH ALLEM, WAS WIR WISSEN / BISHER GESEHEN HABEN. Das ist keine absolute Aussage, es könnte einen Trick geben, den wir nicht in Betracht gezogen haben, es gibt weitaus bessere BinEx-Experten da draußen.
Beachte, dass der Redis-Server stabil blieb - wir haben ihn für Tests aus Docker herausgeholt. Du kannst den Absturz auslösen, indem du den Exploit ein paar tausend Mal abfeuerst, und wir haben noch nicht versucht, diese Brute-Force-Methode mit Versuchen zur Codeausführung zu kombinieren - vielleicht ist das die Lösung.
Wie du siehst, scheint der ursprüngliche PoC mit denselben Problemen zu kämpfen. Er behauptet, "vereinfacht" zu sein, während nicht ganz klar ist, was das Ergebnis sein soll.
Noch nichts ...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Mysteriöserweise ist in den Redis-Patch-Notizen eine völlig andere CVE aufgeführt - ebenfalls angeblich ein Binary Exploit, aber ein viel einfacherer: ein stack-basierter Buffer Overflow mit vermeintlicher RCE:
XACKDEL kann zu Stack-Overflow und potenzieller RCE führenWir haben dazu sogar noch weniger Informationen gefunden. Es ist schon eine Herausforderung, eine nicht zurückportierte Version ohne Selbstkompilierung zu finden, aber vielleicht ist das der Weg, den wir dann gehen müssen.
All diese POTENTIALS - ich habe Potenzial. Jetzt habe ich 2 Potenziale.
62507 ist der richtige Weg ... habe noch keine RCE, aber es sieht einfach und vielversprechend aus ...
War CVE-2025-49844 also nur ein Schwindel? Das koreanische Puzzle hat immer noch keinen Absturz produziert - aber es erzeugt eine völlig andere Ausgabe gegen unsere selbstkompilierte 8.2.2. Ich muss zugeben, sogar ich verfiel dem Gedanken "ja, Absturz, mehr als plausibel, wahrscheinlich einfach ..." und nahm einfach an, dass der Absturzteil von CVE-2025-49844 funktionieren würde. Aber er tat es nie. Entschuldigung, dass ich es vorher falsch gesagt habe, aber jetzt ist es hoffentlich geklärt. CVE-2025-49844 stürzt nicht ab, CVE-2025-62507 stürzt ab.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Kommt das bekannt vor? Keine Ahnung, was die da gemacht haben ... oder ob außer mir niemand nachgeprüft hat? Die Welt ist in letzter Zeit ein ziemlich seltsamer Ort geworden.