浏览 927
最近报告的漏洞(跟踪为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二进制文件,则可以采取几种缓解措施:
各种来源都建议向try_files
NGINX配置添加指令,以验证$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配置取决于上游应用程序的需求。请测试这样的更改以确认它们不会影响您的应用程序。
使用F5 BIG-IP ASM(应用程序安全管理器)保护应用程序。现有的“命令执行”和“服务器端代码注入”签名集包括攻击签名,这些签名会阻止大多数尝试发现和利用此PHP‑FPM漏洞。
编辑器–自发布此博客以来,F5安全团队发布了针对此漏洞的附加签名。有关详细信息,请参见F5 DevCentral。
添加ModSecurity规则以阻止包含可疑%0a
或%0d
字符的请求:
SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"
Wallarm的有关该漏洞的原始报告中描述了此解决方案。它可能会导致误报,并且攻击者可能仍会找到其他方法来利用此漏洞。
您可以使用NGINX Unit来运行PHP应用程序,而不必依赖PHP‑FPM 。NGINX Unit是一种高性能的开源应用程序服务器和流程管理器,除了PHP外,还支持多种语言和框架。它可以自动缩放PHP应用程序以响应负载,并同时运行使用不同PHP运行时的应用程序。我们免费提供二进制文件,源文件和Docker映像。
有关为WordPress(一种流行的,高流量,PHP驱动的应用程序)配置和操作NGINX Unit的说明,请参阅NGINX Unit文档。部署利用了在NGINX Unit 1.11.0及更高版本中支持提供静态文件的支持。
按点赞数排序
按时间排序