open-flaw/cve-2025-49844Prova de conceito de exploit para CVE-2025-49844 visando uma vulnerabilidade de heap no Redis, com análise de crash assistida por GDB e tentativas de fuzzing para alcançar execução de código.
PoC de Revshell feito por IA
Conclusão não testada do PoC Redishell feito por IA.
PoC original:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Peça coreana:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Mais tarde, fomos em frente e usamos GDB - conseguimos obter o endereço base e descobrir mais algumas coisas, mas, acima de tudo, parece que esta não é uma simples vulnerabilidade de heap. Não importa o que tentássemos, era impossível obter execução de código. Crash? Sim. Comandos? Não.
Não somos mais tão bons em engenharia reversa, então não podemos ter certeza, mas, por tudo o que descobrimos ao longo de horas com a ajuda de alguns dos modelos de IA mais fortes, não é possível obter execução de código através desta vuln (ou é uma em mil tentativas, mas isso é puro achismo).
Através de inúmeras tentativas, sempre acabávamos chegando a algo assim, na melhor das hipóteses:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Curioso para ver o PoC real com execução de código.
LEIAM DIREITO, POR FAVOR: Dissemos, POR TUDO O QUE SABEMOS / VIMOS ATÉ AGORA. Isso não é uma afirmação absoluta; pode haver um truque ou armadilha que não consideramos; há BinExers muito melhores por aí.
Observe que o Redis Server permaneceu estável - nós o retiramos do docker para testar. Você pode acionar o crash disparando o exploit algumas milhares de vezes, e ainda não tentamos combinar esse método de força bruta com tentativas de execução de código; pode ser a solução.
Como você pode ver, o PoC original parece sofrer dos mesmos problemas; ele afirma ser "simplificado", embora não esteja totalmente claro qual deveria ser o resultado.
Nada ainda...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Misteriosamente, nas notas de patch do Redis, uma CVE completamente diferente é listada - também supostamente um exploit binário, mas um muito mais simples, um buffer overflow baseado em pilha com suposto RCE:
XACKDEL pode levar a estouro de pilha e potencial RCEhttps://github.com/redis/redis/compare/8.2.2...8.2
Encontramos ainda menos informações sobre isso. Já é desafiador encontrar uma versão sem backport sem compilação própria, mas talvez seja o caminho que teremos de seguir.
Todas essas POTENTIALS - eu tenho potencial. Agora tenho 2 potenciais.
62507 é o caminho... ainda não tenho RCE, mas parece fácil e promissor...
Então, CVE-2025-49844 era apenas um engodo? O quebra-cabeça coreano ainda não produziu um crash - mas produz uma saída completamente diferente contra nosso 8.2.2 compilado por nós mesmos. Tenho que admitir, até eu caí no pensamento "sim, crash, mais do que plausível, provavelmente fácil..." e simplesmente presumi que a parte do crash do CVE-2025-49844 funcionaria. Mas nunca funcionou. Desculpe por ter dito errado antes, mas agora está esclarecido, espero. CVE-2025-49844 não causa crash; CVE-2025-62507 causa.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Parece familiar? Não sei o que fizeram ali... ou se ninguém além de mim verificou? O mundo se tornou um lugar bastante estranho ultimamente.