最近报告的漏洞（跟踪为CVE-2019-11043）可能会影响使用PHP‑FPM执行PHP页面的网站。在NGINX支持的网站上，PHP‑FPM的使用尤其常见，因为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分为两部分。触发漏洞的一种方法是将换行符（%0a）或回车符（%0d）嵌入请求URI中，然后正则表达式无法正确处理该字符。

缓解漏洞

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

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

1. 各种来源都建议向try_filesNGINX配置添加指令，以验证$uri变量是否解析为文件（PHP脚本），404 (Not Found)如果没有，则拒绝带有代码的请求：

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

   请注意，只有NGINX和PHP‑FPM在同一主机上共享相同的docroot时，此缓解措施才有效。

   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映像。

有关为WordPress（一种流行的，高流量，PHP驱动的应用程序）配置和操作NGINX Unit的说明，请参阅NGINX Unit文档。部署利用了在NGINX Unit 1.11.0及更高版本中支持提供静态文件的支持。