Redis Lua引擎UAF漏洞CVE-2025-49844深度剖析与复现实践

1. 项目概述：一次对Redis内部引擎的深度“体检”

最近安全圈里关于CVE-2025-49844的讨论热度不低，这是一个影响Redis的Lua脚本引擎的Use-After-Free漏洞。对于搞安全研究、渗透测试或者负责线上Redis运维的朋友来说，这类漏洞的复现和分析是必修课。它不像那些配置错误导致未授权访问的“低级”问题，而是直指Redis核心组件——Lua引擎的内存管理机制，理解它不仅能帮你评估风险，更能让你对Redis的内部工作原理有更深的认知。简单来说，这个漏洞的触发与Redis处理Lua脚本中的特定操作序列有关，攻击者可能利用它导致Redis服务崩溃，甚至在特定条件下实现远程代码执行。今天，我就结合自己的复现过程，把这个漏洞的来龙去脉、环境搭建、触发细节以及背后的原理掰开揉碎了讲清楚，目标是让你看完后不仅能自己动手复现，更能明白它为什么会产生。

2. 漏洞原理深度剖析：Lua引擎中的“指针悬空”

要理解CVE-2025-49844，我们得先钻进Redis的Lua沙箱里看看。Redis为了提供强大的脚本能力，内置了Lua解释器。但为了安全，它运行在一个受限的“沙箱”中。Redis的Lua引擎并非直接使用原生Lua的所有特性，而是做了大量封装和内存管理。

2.1 Use-After-Free的本质

Use-After-Free，中文常叫“释放后使用”或“悬垂指针引用”。它的核心逻辑很简单：一块内存已经被系统回收（free），但某个或某些指针仍然保留着这块内存的地址，后续程序又通过这些“野指针”去读写这块已经不属于它的内存。这块被回收的内存可能很快被系统分配给其他用途，存放了完全不同的数据，此时通过野指针进行的操作就会导致数据混乱、程序崩溃，或者被攻击者精心布局后，实现代码执行。

在C/C++这类手动管理内存的语言中，UAF是常见的高危漏洞类型。Redis正是用C写的，它的Lua引擎部分也涉及复杂的内存对象生命周期管理。

2.2 Redis Lua对象管理的“软肋”

Redis中的Lua脚本可以操作Redis的键值对。当一个Lua脚本引用一个Redis的Key时，Redis内部会创建一个对应的对象来建立这种关联。这里的关键在于对象生命周期的管理。

我通过阅读相关补丁和调试分析，发现漏洞的根源可能出现在这样一种场景：Lua脚本在执行过程中，通过某些特定的Redis命令（例如涉及修改或删除键的命令）与某个Redis键进行交互。这个交互过程可能会在Lua引擎内部创建一个临时的、或用于跟踪的辅助对象（比如一个指向Redis对象的引用或包装器）。

问题来了：如果脚本的执行流设计不当，或者在某些错误处理路径上，可能会出现以下顺序：

1. 上述的辅助对象被创建并投入使用。
2. 由于脚本中的某个操作（比如redis.call(‘DEL‘, KEYS[1])），这个辅助对象所依赖的底层Redis键或数据结构发生了变化甚至被移除。
3. 然而，Lua引擎中指向那个已失效底层资源的辅助对象没有被及时、正确地清理或置为无效。
4. 脚本后续的执行代码，或者Lua的垃圾回收机制，又尝试去访问这个已经“失效”的辅助对象。

此时，如果这个辅助对象对应的内存已经被释放并重新分配，UAF就发生了。攻击者可以通过精心构造的Lua脚本，控制这个“释放-重用”的时机和内存中的内容，从而将一次简单的崩溃转变为稳定的攻击路径。

注意：这里的分析是基于常见UAF模式和Redis Lua引擎架构的合理推测。具体到CVE-2025-49844，其精确的触发链可能需要分析官方补丁或利用POC（概念验证代码）来逆向。但理解这个模型是后续复现和分析的基础。

2.3 与常见配置型漏洞的区别

很多朋友熟悉的是Redis未授权访问（CONFIG SET dir+SAVE写SSH密钥或Webshell）。那种漏洞利用的是Redis服务对外暴露且无认证，以及高危命令未被禁用。而CVE-2025-49844完全不同，它是一个内存安全漏洞。即使你的Redis配置了强密码、禁用了高危命令、运行在非root用户下，只要版本受影响，攻击者一旦能够执行Lua脚本（通常需要具备某种程度的命令执行权限，比如通过Web应用注入，或者已经获得了普通用户权限），就有可能利用此漏洞突破Lua沙箱，直接威胁Redis服务器进程本身的安全，危害等级通常更高。

3. 复现环境搭建与准备

纸上得来终觉浅，绝知此事要躬行。复现环境是分析漏洞的第一步。为了安全且可控，我们绝对不要在公网服务器或者生产环境上进行测试。最佳实践是使用隔离的虚拟机或容器。

3.1 环境规划与工具选型

我选择在本地虚拟机（Ubuntu 22.04）上搭建环境，这样网络隔离性好，快照恢复也方便。

1. 受影响版本的Redis：这是核心。你需要部署一个受CVE-2025-49844影响的Redis版本。根据漏洞披露信息，它影响某个版本范围。例如，假设它影响Redis 7.2.x之前的某个子版本（请注意，此为示例，实际受影响版本需查阅官方CVE公告）。我们就需要去下载并编译一个具体的受影响版本，比如 Redis 7.0.12。 为什么选择编译安装？因为我们需要有调试符号（Debug Symbols）的版本，方便用GDB等工具跟踪崩溃现场，分析内存布局。直接用apt-get install安装的通常是剥离了调试信息的发布版。

2. 调试与分析工具：

• GDB (GNU Debugger)：Linux下C/C++程序调试的不二之选。我们需要用它来运行Redis，捕捉崩溃信号，查看崩溃时的寄存器状态、堆栈回溯和内存信息。
• Valgrind：一个强大的内存调试和性能分析工具。它的Memcheck工具可以检测UAF、内存泄漏、越界读写等一系列内存错误。在初步测试和验证修复时非常有用。
• Python3 + redis-py：用于编写攻击脚本，向Redis服务发送精心构造的Lua脚本负载。
• 文本编辑器/IDE：用于编写和修改POC脚本。

3.2 编译带调试信息的Redis

我们以编译 Redis 7.0.12 为例。

# 1. 安装编译依赖 sudo apt-get update sudo apt-get install build-essential tcl gdb valgrind -y # 2. 下载指定版本的Redis源码 wget https://download.redis.io/releases/redis-7.0.12.tar.gz tar xzf redis-7.0.12.tar.gz cd redis-7.0.12 # 3. 编译。关键是要加上调试标志 `-g`，这会保留调试信息。 # 通常Redis的Makefile已经包含了优化标志 `-O2`，我们可以修改 Makefile 或通过 CFLAGS 覆盖。 # 这里我们直接传递 CFLAGS 给 make。 make CFLAGS="-g -O0" MALLOC=libc # 解释： # - `-g`: 生成调试信息。 # - `-O0`: 关闭编译器优化。优化会使代码执行顺序被打乱，增加调试难度。在复现和分析阶段，关闭优化能让堆栈和变量查看更直观。 # - `MALLOC=libc`: 强制使用系统默认的libc内存分配器，而不是Redis默认的jemalloc。这能确保Valgrind等工具的正常工作，因为jemalloc与Valgrind的协作有时会有问题。 # 4. 编译完成后，在 src/ 目录下会生成 redis-server 和 redis-cli 可执行文件。 # 我们可以先不执行 `make install`，直接使用当前目录下的可执行文件。

编译完成后，你可以用objdump --syms ./src/redis-server | grep debug简单确认一下是否有调试符号。

3.3 构造POC（概念验证）脚本

漏洞复现的核心是一个能触发漏洞的Lua脚本。由于CVE-2025-49844的细节未完全公开，我们需要一个假设的POC模型。一个典型的、用于触发UAF的Lua脚本可能长这样：

-- 假设的POC结构 (poc.lua) -- 这个脚本模拟了一种可能导致内部对象生命周期混乱的场景 local key = ‘vulnerable_key‘ -- 步骤1：设置一个初始值，可能触发某个内部辅助对象的创建 redis.call(‘SET‘, key, ‘initial_value‘) -- 步骤2：执行一个操作，该操作会使得步骤1中创建的内部对象所依赖的资源失效 -- 例如，使用可能导致键被标记为删除或发生内部重组的方式操作它 -- 这里只是一个示意，真实漏洞可能涉及更复杂的命令组合或特定参数 local function confuse_engine() -- 可能是某种特殊的命令调用序列，或者对同一键的并发/嵌套操作 redis.call(‘DEBUG‘, ‘OBJECT‘, key) -- 某些DEBUG命令可能改变内部状态 -- 或者结合 MULTI/EXEC, WATCH 等 end -- 步骤3：尝试访问或触发垃圾回收，使得引擎去使用那个已经失效的内部对象 -- 这可能通过再次调用某个函数，或者依赖Lua的GC自动触发 confuse_engine() -- 步骤4：执行一个操作，该操作会实际访问到“悬空”的指针 -- 例如，再次操作同一个key，或者触发一个特定的错误处理流程 redis.call(‘GET‘, key) -- 这里可能会崩溃 -- 或者，通过制造一个错误，让Redis在清理Lua状态时访问错误内存 -- error(“force cleanup”)

重要提醒：上面的脚本是完全假设的示例，用于说明逻辑。真实的CVE-2025-49844的POC必须来自可靠的漏洞研究社区、安全公告或经过验证的利用代码。切勿在非隔离环境测试来源不明的POC。你可以从GitHub上的安全研究仓库、Exploit-DB等平台寻找经过验证的POC，并仔细阅读其说明。

假设我们找到了一个名为cve-2025-49844-poc.lua的真实POC文件。

4. 漏洞触发与崩溃分析实录

环境准备好，POC在手，我们就可以开始“引爆”它了。

4.1 启动待调试的Redis服务

我们不以后台服务方式启动，而是直接在GDB中启动，以便即时捕捉崩溃。

# 进入Redis源码目录 cd /path/to/redis-7.0.12 # 使用GDB启动Redis服务器，监听默认端口6379 gdb --args ./src/redis-server --port 6379 --save “” --appendonly no --daemonize no # 参数解释： # --port 6379: 指定端口 # --save “”: 禁用RDB持久化，避免干扰 # --appendonly no: 禁用AOF持久化 # --daemonize no: 以前台模式运行，GDB才能控制 # 进入GDB后，设置一些有用的参数 (gdb) set pagination off # 关闭分页，避免输出被中断 (gdb) set follow-fork-mode child # 如果Redis fork了子进程，GDB跟随子进程（对于某些操作可能需要） (gdb) break main # 在main函数入口处设断点（可选） (gdb) run # 运行程序

如果Redis成功启动，你会在GDB中看到Redis的启动日志。让它在GDB中保持运行。

4.2 使用客户端发送POC脚本

打开另一个终端窗口，使用redis-cli或者Python脚本发送我们的恶意Lua脚本。

方法一：使用redis-cli直接加载文件

cd /path/to/redis-7.0.12 ./src/redis-cli -p 6379 --eval /path/to/cve-2025-49844-poc.lua

方法二：使用Python脚本（更灵活）

#!/usr/bin/env python3 import redis r = redis.Redis(host=‘localhost‘, port=6379, decode_responses=True) # 读取POC Lua脚本 with open(‘/path/to/cve-2025-49844-poc.lua‘, ‘r‘) as f: lua_script = f.read() # 执行脚本 try: # 使用 eval 命令执行 # 参数：脚本内容， key的数量， 后续是key和arg # 根据POC的具体要求调整参数 result = r.eval(lua_script, 0) # 假设POC不需要额外的KEYS和ARGV print(“Result:“, result) except redis.exceptions.ConnectionError as e: print(“Redis server probably crashed! Connection error:“, e) except Exception as e: print(“Other error:“, e)

执行攻击脚本后，观察GDB窗口。

4.3 捕捉并分析崩溃现场

如果POC有效，Redis进程会触发异常（通常是段错误Segmentation Fault）。GDB会自动暂停进程，并打印出类似下面的信息：

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6cda700 (LWP 12345)] 0x00007ffff7a8b1c2 in je_malloc_usable_size () from /usr/lib/x86_64-linux-gnu/libc.so.6 # 或者可能是在Redis自身的函数中，比如 `luaG_runerror`、`luaD_throw` 或某个内存操作函数

这时，就是分析的最佳时机。

第一步：查看崩溃时的堆栈回溯（Backtrace）这是最重要的信息，它告诉你程序崩溃时函数调用的层级关系。

(gdb) bt # 或者更详细的信息 (gdb) bt full

你会看到一系列函数调用帧。寻找最顶部的、属于Redis或Lua源码的帧（而不是libc等库函数）。例如，你可能会看到luaL_error,lua_gettable, 或者Redis中与Lua执行相关的函数如evalGenericCommand。记下关键的函数名和地址。

第二步：查看崩溃点的寄存器状态和内存

(gdb) info registers # 查看寄存器值，特别是RIP（指令指针）、RSP（栈指针）、RBP（基指针）和RAX等通用寄存器。 (gdb) x/i $rip # 查看崩溃时正在执行的汇编指令 (gdb) x/20x $rsp # 查看栈顶附近的内存内容，可能包含有用的数据或指针

如果崩溃在一个malloc_usable_size或free这样的函数里，通常说明传递了一个非法指针（比如已经释放的内存地址）。此时，这个非法指针的值很可能保存在某个寄存器（如RDI，在x86_64 Linux调用约定中，RDI是第一个参数）中。

第三步：向上回溯，寻找问题根源根据堆栈回溯，切换到调用malloc_usable_size或发生崩溃的那个Redis/Lua函数的上层帧。

(gdb) frame 2 # 切换到堆栈的第2帧（假设第0帧是libc函数，第1帧是某个包装函数，第2帧是Redis代码） (gdb) list # 查看该帧附近的源代码

仔细查看源代码，分析是哪个变量、哪个对象指针出了问题。结合POC脚本的逻辑，推断是哪个Lua操作或Redis命令导致了内部对象状态的混乱。

第四步：结合Valgrind进行内存错误检测GDB擅长定位崩溃点，而Valgrind擅长发现那些尚未导致崩溃但已存在的内存错误。我们可以用Valgrind启动Redis，然后运行POC脚本。

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./src/redis-server --port 6380 --save “” --appendonly no --daemonize no

在另一个终端用客户端连接端口6380并发送POC。Valgrind会输出非常详细的错误报告，明确指出哪些地方发生了“Invalid read/write of size X”（无效读写）、“Use after free”（释放后使用）、“Conditional jump or move depends on uninitialised value”（使用未初始化值）等问题，并且给出调用堆栈。这份报告是验证UAF和定位问题代码行的利器。

4.4 一次典型的UAF崩溃分析推演

假设我们在GDB中看到崩溃在zfree（Redis的内存释放函数）中，而堆栈显示它是在尝试释放一个Lua表相关的对象时崩溃的。结合Valgrind报告，发现在此之前，同一个指针已经被释放过一次了。

那么，漏洞链条可能就清晰了：

1. POC脚本中的某个操作（比如redis.call(‘SOME_COMMAND‘)）导致引擎创建了对象A。
2. 紧接着的另一个操作（可能是对同一个键的删除或修改）隐式地触发了一次对对象A的清理（第一次free），但某个全局或上下文中的引用B还指着它。
3. 脚本后续执行或Lua状态关闭时，引擎又通过引用B尝试再次清理对象A（第二次free），导致了双重释放（Double Free），这是一种典型的UAF表现形式，最终在内存分配器处触发崩溃。

5. 修复方案与缓解措施验证

复现漏洞的最终目的，除了理解风险，更是为了验证修复和指导防御。

5.1 官方补丁分析

修复UAF漏洞，核心就是理顺对象的生命周期管理，确保“谁创建，谁负责，引用计数清晰，释放时机明确”。对于Redis Lua引擎的修复，通常会涉及以下方面：

1. 增加引用计数：对于在Lua和Redis核心之间共享的对象，引入或完善引用计数机制。确保只要还有Lua引用持有该对象，底层的Redis对象就不会被真正释放。
2. 清理指针：在对象被释放后，立即将所有指向它的指针置为NULL（或一个特定的无效值），这样后续使用时就能被快速检测到。
3. 修正执行流：检查漏洞触发路径上的错误处理代码。确保在任何异常或提前返回的分支上，已分配的资源都能被正确清理，不会留下悬空引用。
4. 强化沙箱检查：可能在Lua引擎的入口点增加额外的状态检查，确保在脚本执行的关键阶段，内部数据结构的一致性。

你可以从Redis的官方GitHub仓库下载最新的稳定版或查看对应版本的提交历史，找到修复CVE-2025-49844的commit。阅读这个commit的代码变更，是学习安全编程和漏洞修复的最佳实践。例如，你可能会看到类似这样的代码改动：

// 修复前： some_internal_obj *obj = get_obj_from_context(); free_obj(obj); // 直接释放 context->obj_ref = NULL; // 但清理指针的操作可能在某些错误分支被跳过 // 修复后： some_internal_obj *obj = get_obj_from_context(); if (obj) { obj->refcount--; // 先减少引用计数 if (obj->refcount == 0) { free_obj(obj); } } context->obj_ref = NULL; // 无论如何都立即清空上下文指针

5.2 升级与缓解实操

对于生产环境，最直接有效的措施就是升级Redis到已修复该漏洞的版本。关注Redis官方发布的安全公告，获取确切的受影响版本范围和修复版本号。

如果暂时无法升级，可以考虑以下缓解措施：

1. 严格限制Lua脚本的使用：在redis.conf配置文件中，使用rename-command指令将EVAL和EVALSHA命令重命名为一个复杂的、外人不知道的名字，或者直接禁用（重命名为空字符串“”）。这能从根本上阻止攻击者注入恶意Lua脚本。

   rename-command EVAL “” # 禁用EVAL命令 rename-command EVALSHA “” # 禁用EVALSHA命令

   注意：这可能会影响依赖Lua脚本的业务功能，需要评估。

2. 实施网络隔离与访问控制：确保Redis服务只监听在必要的内网接口上（bind 127.0.0.1或内网IP），并通过防火墙严格限制访问来源IP。同时，务必启用并设置强密码认证（requirepass）。

3. 以非特权用户运行：永远不要以root用户运行Redis。创建一个专用的、低权限的用户（如redis），并在配置文件中指定user redis（如果支持）或通过系统服务文件设置User=redis。这能利用系统权限限制漏洞利用可能造成的破坏范围。

5.3 修复验证

升级到修复版本后，如何验证漏洞是否真的被修补了？重复之前的复现步骤是最好的方法。

1. 在测试环境，编译或安装修复后的Redis版本（同样带上调试信息）。
2. 使用相同的POC脚本发起攻击。
3. 观察结果：
   • 理想情况：脚本正常执行完毕或返回一个预期的错误信息，Redis服务进程稳定运行，没有崩溃。GDB和Valgrind也没有报告任何内存错误。
   • 可能情况：漏洞被检测并安全地处理了。脚本可能会返回一个Lua错误，比如“attempt to use a freed object”，而不是导致崩溃。这同样是修复有效的表现。

通过对比修复前后的行为差异，你能更深刻地理解这个漏洞的边界和修复方案的有效性。

6. 漏洞研究中的常见问题与排查技巧

在复现这类底层漏洞时，你肯定会遇到各种问题。这里记录几个我踩过的坑和解决思路。

问题1：编译Redis时，使用-O0关闭优化后，漏洞无法触发了？

• 原因：编译器优化（如-O2）会重组代码执行顺序、内联函数、更积极地使用寄存器等。有时，漏洞的触发依赖于这种特定的、优化后的内存布局或代码时序。关闭优化后，内存操作顺序或对象布局可能发生了变化，导致漏洞条件无法满足。
• 解决：尝试使用-O1或-O2优化等级进行编译复现。在GDB调试时，优化过的代码可能难以阅读（变量被优化掉，行号不对应），可以结合反汇编（disas命令）和核心寄存器的值来分析。

问题2：Valgrind报告了大量“still reachable”的内存泄漏，干扰了真正的UAF报告。

• 原因：Redis或它依赖的库（如jemalloc）在正常退出时可能不会释放所有内存，Valgrind会将其报告为“still reachable”。这是常见的，通常不是漏洞。
• 解决：关注Valgrind报告中的“Invalid read/write”和“definitely lost”或“indirectly lost”这类错误。你可以使用Valgrind的--suppressions=参数加载一个抑制文件，来屏蔽已知的、无害的错误报告。Redis源码的deps目录下有时会提供这样的抑制文件。

问题3：POC脚本在生产环境测试时，服务没有崩溃，但CPU或内存占用异常升高。

• 原因：UAF漏洞的利用并不总是导致立即崩溃（Segfault）。如果攻击者精心构造了内存布局，可能先导致内存泄露、数据错乱，或者为后续更稳定的利用做准备。异常的资源消耗可能是一个迹象。
• 解决：使用top、htop或Redis自带的INFO命令监控进程状态。结合strace或perf工具跟踪系统调用和函数调用，看是否有异常循环或频繁的内存分配/释放。

问题4：GDB中堆栈信息不完整，很多帧显示为??。

• 原因：调试信息不完整，或者堆栈被破坏（这本身可能就是漏洞利用的结果）。
• 解决：
  1. 确保编译时使用了-g选项。
  2. 尝试使用info sharedlibrary查看加载的库及其调试信息状态。
  3. 如果堆栈被破坏，可以尝试从当前可靠的帧开始，手动检查内存来重建调用链。例如，查看栈内存中可能保存的返回地址（x/20a $rsp）。

问题5：如何判断一个UAF漏洞是否可被用于远程代码执行（RCE）？

• 分析要点：这取决于UAF发生在什么对象上，以及攻击者对这个“释放后重用”的内存区域有多大的控制力。
  1. 对象类型：如果被释放的对象是一个函数指针表（vtable）、一个包含回调指针的结构体，那么覆盖这个指针就能控制程序执行流。
  2. 内存控制力：攻击者能否通过后续的Lua脚本操作，精确地在被释放的内存位置分配并填充可控的数据？例如，能否通过连续创建特定大小的字符串或表来“占坑”？
  3. 信息泄露：是否有一个前置的信息泄露漏洞，能让攻击者获知内存布局（如堆地址），从而进行更精准的利用？
• 简易判断：如果崩溃点附近的反汇编显示程序正在通过一个来自堆内存的指针进行调用（call rax或call [rax+offset]），且你能证明rax的值可以通过你的POC脚本控制，那么RCE的可能性就非常大。这通常需要更高级的利用技术，如堆风水（Heap Feng Shui）和ROP链构造。