使用 NGINX 解决 PHP-FPM 漏洞 (CVE-2019-11043)

最近报告的一个漏洞（编号为CVE-2019-11043 ）可能会影响使用 PHP‑FPM 执行 PHP 页面的网站。 PHP‑FPM 在由 NGINX 驱动的网站上尤为常见，因为 NGINX 没有进程内 PHP 运行时。 相反，NGINX 充当应用服务器和进程管理器（如 PHP-FPM）的反向代理。

该漏洞存在于 PHP‑FPM 本身，而不是 NGINX，因此唯一保证的解决方案是升级到 PHP 版本的修补版本（或更高版本）： PHP 7.1.33 、 PHP 7.2.24或PHP 7.3.11 。

该漏洞的本质是什么？

NGINX 使用 FastCGI 协议与 PHP‑FPM 通信。 每个 FastCGI 消息包含一组环境变量。 其中之一PATH_INFO是从其他请求参数派生而来的。 如果其值意外为空，这最终可能会导致PHP‑FPM 二进制文件中的内存损坏。 可以利用这种情况并让 PHP‑FPM 二进制文件在本地服务器上运行任意命令。

此漏洞可通过常见的 NGINX 配置触发，其中 NGINX 使用fastcgi_split_path_info指令中的正则表达式将请求 URI 拆分为两部分。 触发此漏洞的一种方法是在请求 URI 中嵌入换行符（ ％0a ）或回车符（ ％0d ），而正则表达式则无法正确处理这些字符。

缓解漏洞

如上所述，解决此漏洞的唯一可靠方法是升级到 PHP 版本的修补版本（或更高版本）： PHP 7.1.33 、 PHP 7.2.24或PHP 7.3.11 。

如果您无法立即升级 PHP 二进制文件，您可以采取几种部分缓解措施：

1. 各种消息来源建议在 NGINX 配置中添加try_files指令，以验证$uri变量是否解析为文件（PHP 脚本），并使用代码拒绝请求404（未找到）如果没有：

   位置 ~ [^/]\.php(/|$) { fastcgi_split_path_info ^(.+?\.php)(/.*)$;
   fastcgi_param PATH_INFO $fastcgi_path_info;
   try_files $uri =404;
   #...
   }

   请注意，仅当 NGINX 和 PHP-FPM 在同一主机上共享相同的文档根目录时，此缓解措施才有效。

   PHP 配置根据上游应用的需求而有所不同。 请测试此类更改以验证它们不会影响您的应用。

2. 使用F5 BIG-IP ASM（应用安全管理器）来保护应用。 现有的“命令执行”和“服务器端代码注入”签名集包含可阻止大多数发现和利用此 PHP‑FPM 漏洞的尝试的攻击签名。

   编辑 – 自本博客发布以来，F5 安全团队已发布了针对此漏洞的附加签名。 详情请参见F5 DevCentral 。

3. 添加 ModSecurity 规则来阻止包含可疑%0a或%0d字符的请求：

   SecRule REQUEST_URI“@rx %0(a|A|d|D)”“id:1,phase:1,t:lowercase,deny”

   Wallarm 在关于该漏洞的原始报告中描述了该解决方案；它可能会导致误报，并且攻击者仍可能找到其他方法来利用该漏洞。

使用不同的 PHP 进程管理器

您可以使用NGINX Unit来运行 PHP应用，而不必依赖 PHP‑FPM。 NGINX Unit 是一个高性能、开源应用服务器和进程管理器，除了 PHP 之外，还支持多种语言和框架。 它可以根据负载自动扩展 PHP应用，并同时运行使用不同 PHP 运行时的应用。 我们免费提供二进制文件、源代码和 Docker 镜像。

请参阅NGINX Unit 文档，了解如何为 WordPress（一种流行的、高流量的、由 PHP 驱动的应用）配置和操作 NGINX Unit 的说明。 该部署利用了NGINX Unit 1.11.0及更高版本对提供静态文件的支持。