IngressNightmare: CVE-2025-1974 远程代码执行漏洞及补救措施

2025 年 5 月，一个被称为 IngressNightmare 的关键安全漏洞（CVE-2025-1974）被公开披露，该漏洞影响了广泛部署在云原生基础架构中的 Kubernetes ingress-nginx 控制器。该漏洞允许未经身份验证的攻击者向 NGINX 注入任意配置，可能导致未经授权的 RCE（远程代码执行）和整个集群崩溃。

作为OPSWAT 研究金计划的一部分，我们的研究员进行了深入的技术分析，以更好地了解其根本原因、开发路径以及围绕这一严重问题的缓解策略。

1. 每个配置都会被解析并传递给generateTemplate，以便根据预定义的 NGINX 模板进行格式化。
2. 随后，testTemplate会根据底层 NGINX 二进制验证生成的配置。

所有 NGINX 配置都基于 ingress-nginx 源代码中 nginx.tmpl 文件的预定义模板：

在生成模板（generateTemplate）函数中，配置将按以下代码片段进行处理：

然而，输入验证和消毒并不充分。具体来说，Ingress 对象的uid字段被直接插入 NGINX 配置模板，从而创建了一个注入点。攻击者可通过提供精心制作的输入（如uid="1234#;\n\n}\n}\n injection_value"）来利用这一点。

这种恶意输入允许向 NGINX 模板注入全局范围，使攻击者能够触发任意 NGINX 指令，并可能实现 RCE。

要利用这个漏洞，攻击者需要确定一个能够执行恶意代码的指令。最初，我们的研究人员发现load_module指令可能有用，因为该指令允许 NGINX 加载外部插件。但是，只有在配置解析的早期阶段才允许使用该指令，这与我们的注入点不符。

为了解决这一难题，我们继续深入研究，最终发现了ssl_engine指令，其描述为 "在配置测试过程中，该模块可能会被 OpenSSL 动态加载"。这引起了我们对动态加载模块功能的好奇，因此有必要进行更深入的研究。

启动时，NGINX会加载初始状态，然后逐行解析配置文件。每条指令都由nginx_command_t结构处理，其中ssl_engine指令直接调用ngx_openssl_commands。

在分析ngx_openssl_commands函数时，我们的研究人员发现它依赖于 OpenSSL 支持，特别是用于硬件加速 SSL 模块的ENGINE_by_id函数。

在分析ENGINE_by_id函数时，我们发现它可以动态加载共享库。此外，如果库在编译时使用了__attribute__((constructor))扩展，相关函数就可以在加载时立即执行。这表明利用ssl_engine指令，攻击者可以在主机上加载任意共享库，从而可能导致RCE。

默认情况下，当传入请求超过 8KB 时，NGINX 会将请求正文写入位于 /tmp/nginx/client-body 的临时文件，文件名格式为 cfg-{random_value}。这些临时文件最多可在接收到的成功信息块之间保留 60 秒。

将部分请求正文写入临时文件后，NGINX 会推迟删除，直到收到整个正文。如果请求仍不完整，且在长达 60 秒的时间内未收到任何数据，文件最终会被清除。但是，攻击者可以通过故意扣留最后一块数据来保持临时文件的使用，使其成为可利用的漏洞。

虽然上传的文件内容可以控制，但由于文件名是随机的，因此很难在文件系统中找到它。存储路径可以使用client_body_temp_path 进行配置，但文件名是在运行时随机生成的，因此无法预测。这种随机性极大地阻碍了目标访问，即使是通过暴力手段。为了克服这一问题，研究小组利用了 Linux 操作系统固有的行为。请看下面的例子：

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

编译后，生成的共享库大小刚好超过 8KB，因此 NGINX 可以对其进行缓冲，而无需额外填充。

然后，我们的研究人员用夸大的Content-Length值（如 1MB）伪造了一个请求，以引入大小不匹配。这导致 NGINX 对整个正文进行缓冲，而不是立即处理，从而确保共享对象被写入可预测的位置。

成功的 RCE 要求ssl_engine指令引用缓冲文件的正确路径。这可以通过自动暴力脚本来实现，该脚本会系统地遍历进程 ID 和文件描述符的可能组合，以识别指向缓冲共享对象的有效符号链接。

以下是生成的 NGINX 模板示例，该模板触发了漏洞利用。

成功利用后，攻击者可以在 ingress-nginx pod 的上下文中获得 shell 访问权限，默认情况下，该 pod 可以访问敏感的 Kubernetes 集群机密。