Redis Lua Sandbox Risks and Hardening: A Review of CVE-2022-0543

免责声明：本文为个人技术学习与工程实践笔记，所涉操作仅应在获得授权的环境中进行。因不当使用造成的后果由使用者自行承担。

Redis 作为键值存储数据库为人熟知，但较少有人注意到它内置了 Lua 脚本引擎，允许在一次请求中原子性地执行服务端脚本。这一能力在出题与学习场景中常被用来设计有挑战性的题目；从防御角度看，它同时也是一块值得单独审视的风险面——脚本运行在服务端进程内部，一旦沙箱边界失效，受影响的不是单个键，而是整台主机。

官方仓库：https://github.com/redis/redis

与 Lua 相关的常用指令如下：

• EVAL，直接执行 Lua 脚本
• EVALSHA，根据脚本的 SHA1 校验和执行
• SCRIPT LOAD，将脚本加载到 Redis 缓存中，但不立即执行，返回 SHA1
• SCRIPT EXISTS sha1，检查某个 SHA1 对应的脚本是否已经在缓存里
• SCRIPT FLUSH，清空所有的 Lua 脚本缓存（在生产环境中执行这个会直接导致所有依赖 EVALSHA 的业务瞬间崩溃）
• SCRIPT KILL，终止正在运行的长耗时脚本
• redis.call() / redis.pcall()，在脚本内调用 Redis 命令

Lua 沙箱的边界

常规调用形式如下，末尾的 0 表示脚本不访问任何键：

eval 'return 1' 0

Redis 对脚本环境做了裁剪，意在让脚本停留在数据操作的范围内：os、io 这类可以直接与操作系统交互的标准库默认不可用，脚本因此无法打开进程或读写任意文件。这一层限制是沙箱的主要边界，一旦被绕过，脚本获得的就是与 Redis 进程同等的执行能力。

CVE-2022-0543：由打包方式引入的沙箱逃逸

CVE-2022-0543 的根源不在 Redis 自身的脚本沙箱实现，而在于 Debian、Ubuntu 等发行版在打包 Redis 时，为了减小体积，将 Lua 解释器作为动态链接库（Shared Library）加载。这种打包方式使 Lua 的 package 库在部分环境中仍然可用；而 package 提供的动态加载能力可以让脚本加载外部的共享库并调用其中的函数，沙箱边界因此被绕过，脚本得以间接执行系统命令。

该问题的影响范围取决于发行版与 Redis 版本的组合，早期的 Redis Server 受其影响；在已修复的高版本上，同一条路径会直接返回错误，不再具备逃逸条件。

判断一个实例是否具备逃逸前提，可以先看两个条件：Redis 加载 Lua 解释器的方式是动态链接库还是内置实现，以及脚本环境中 package 库是否可用。后者可以在隔离实例中通过 EVAL 检查其类型来确认。需要强调的是，这类风险的处置重点在于版本与部署方式，而不是在脚本层追加关键字过滤——决定沙箱是否成立的从来不是脚本内容，而是运行环境。

加固与排查

修复方案

• 将 Redis 及其 Lua 依赖升级到发行版或上游已发布的修复版本，具体的版本对应关系以发行版安全公告为准。
• 避免长期维持「发行版自带的 Lua 动态库 + 旧版本 Redis」这一组合；若条件允许，使用上游官方构建的制品可以减少发行版打包差异带来的额外风险。
• 升级后应回归验证脚本业务，确认既有 EVALSHA 缓存与脚本行为未发生变化。

暴露面收敛

• Redis 不应直接监听公网。将其绑定到内网地址或本地回环，并通过防火墙只放行必要来源；protected-mode 与 requirepass 至少启用其一，生产环境建议同时启用。
• 利用 Redis 提供的 ACL 能力为业务账号收敛命令权限：默认账号不授予 EVAL、EVALSHA、SCRIPT、MODULE 等高风险命令，仅对确有脚本需求的账号按最小权限单独放开。
• 如果业务并不依赖服务端脚本，可考虑在 ACL 或代理层直接拦截 EVAL/EVALSHA/SCRIPT 系列命令，从架构上消除该类风险。

运行环境最小权限

• Redis 以专用低权限账号运行，只对数据目录可写，不挂载无关的宿主机路径，容器场景下不暴露 Docker socket，使得即使脚本沙箱被绕过，进程可触及的范围也有限。
• 不要将 Redis 与高权限业务进程部署在同一主机或同一容器内，以降低逃逸成功后的横向影响。

检测与排查清单

1. 审计日志：关注 EVAL/EVALSHA/SCRIPT LOAD 的调用来源与频率，特别是来自非业务网段的调用；SCRIPT FLUSH 的出现意味着业务故障风险。
2. 进程行为：Redis 进程正常情况下不应派生 shell、创建子进程，也不应出现对 /tmp 等目录的异常写入。可在主机侧 EDR 或审计规则中对 redis-server 的子进程创建行为告警。
3. 版本核对：比对实际使用的 Lua 解释器加载方式与 Redis 版本组合，确认实例是否仍处于受影响范围。
4. 配置核查：确认监听地址、认证、ACL 与命令拦截策略是否已按最小权限落地，并纳入配置基线定期巡检。