open-flaw/cve-2025-49844Эксплойт-концепт для CVE-2025-49844, нацеленный на уязвимость кучи Redis, с анализом сбоев с помощью GDB и попытками фаззинга для достижения выполнения кода.
PoC реверс-шелла, созданный ИИ
Непроверенное завершение PoC Redishell, созданного ИИ.
Оригинальный PoC:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Корейская часть:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Позже мы подключили GDB — нам удалось получить базовый адрес и выяснить кое-что ещё, но главное — похоже, это не простая уязвимость кучи. Что бы мы ни пробовали, получить выполнение кода не удавалось. Краш? Да. Команды? Нет.
Мы больше не сильны в реверсе, поэтому не можем быть уверены, но, судя по всему, что мы нашли за часы работы с помощью одних из самых сильных ИИ-моделей, через эту уязвимость невозможно получить выполнение кода (или это одна попытка из тысячи, но это просто чистое гадание).
После многочисленных попыток мы в лучшем случае оказывались где-то здесь:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Любопытно увидеть настоящий PoC с выполнением кода.
ПРОЧТИТЕ ВНИМАТЕЛЬНО: Мы сказали, ИЗ ВСЕГО, ЧТО МЫ ЗНАЕМ / ВИДЕЛИ НА ДАННЫЙ МОМЕНТ. Это не абсолютное утверждение, может быть, есть какой-то трюк или уловка, которую мы не учли, есть гораздо более сильные специалисты по бинарным эксплойтам.
Обратите внимание, что Redis Server оставался стабильным — мы вытащили его из docker для тестирования. Вы можете вызвать краш, запустив эксплойт пару тысяч раз, и мы ещё не пробовали комбинировать этот метод перебора с попытками выполнения кода; возможно, это решение.
Как видите, оригинальный PoC, похоже, страдает от тех же проблем; он утверждает, что является «упрощённым», хотя не совсем понятно, каким должен быть результат.
Пока ничего...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Загадочным образом в примечаниях к патчам Redis указан совершенно другой CVE — тоже якобы бинарный эксплойт, но гораздо более простой: переполнение буфера на основе стека с предполагаемым RCE:
XACKDEL может привести к переполнению стека и потенциальному RCEОб этом мы нашли ещё меньше информации. Уже сейчас сложно найти версию без бэкпортов, не компилируя самостоятельно, но, возможно, это тот путь, который нам придётся выбрать.
Все эти POTENTIALS — у меня есть потенциал. Теперь у меня 2 потенциала.
62507 — вот куда надо идти... RCE пока нет, но выглядит легко и многообещающе...
Так неужели CVE-2025-49844 — просто обман? Корейская головоломка так и не вызвала краш — но она выдаёт совершенно другой результат против нашего самостоятельно собранного 8.2.2. Признаюсь, даже я поддался мысли «да, краш, более чем правдоподобно, наверное, легко...» и просто предположил, что краш-часть CVE-2025-49844 будет работать. Но она никогда не работала. Извините, что раньше сказал неправильно, но теперь, надеюсь, всё прояснилось. CVE-2025-49844 не вызывает краш, а CVE-2025-62507 вызывает.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Выглядит знакомо? Я не знаю, что они там сделали... или никто, кроме меня, не проверял? В последнее время мир стал довольно странным местом.