位置: 编程技术 - 正文
PHP-CGI远程代码执行漏洞分析与防范(phpcgi远程代码执行漏洞)
编辑：rootadmin推荐整理分享PHP-CGI远程代码执行漏洞分析与防范(phpcgi远程代码执行漏洞)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:php远程代码执行,php远程控制,php远程开发,PHPCGI远程代码执行漏洞使用哪个参数来执行任意代码,PHPCGI远程代码执行漏洞使用哪个参数来执行任意代码,phpcgi远程代码执行漏洞执行任意代码,phpcgi远程代码执行漏洞,PHPCGI远程代码执行漏洞使用哪个参数来执行任意代码,内容如对您有帮助，希望把文章链接给更多的朋友！
CVE--出来时据说是“PHP远程代码执行漏洞”，曾经也“轰动一时”，当时的我只是刚踏入安全门的一个小菜，直到前段时间tomato师傅让我看一个案例，我才想起来这个漏洞。通过在 Vulhub 中对这个漏洞环境的搭建与漏洞原理的分析，我觉得还挺有意思的，故写出一篇文章来，和大家分享。
首先，介绍一下PHP的运行模式。
下载PHP源码，可以看到其中有个目录叫sapi。sapi在PHP中的作用，类似于一个消息的“传递者”，比如我在《 Fastcgi协议分析 && PHP-FPM未授权访问漏洞 && Exp编写 》一文中介绍的fpm，他的作用就是接受Web容器通过fastcgi协议封装好的数据，并交给PHP解释器执行。
除了fpm，最常见的sapi应该是用于Apache的mod_php，这个sapi用于php和apache之间的数据交换。
php-cgi也是一个sapi。在远古的时候，web应用的运行方式很简单，web容器接收到http数据包后，拿到用户请求的文件（cgi脚本），并fork出一个子进程（解释器）去执行这个文件，然后拿到执行结果，直接返回给用户，同时这个解释器子进程也就结束了。基于bash、perl等语言的web应用多半都是以这种方式来执行，这种执行方式一般就被称为cgi，在安装Apache的时候默认有一个cgi-bin目录，最早就是放置这些cgi脚本用的。
但cgi模式有个致命的缺点，众所周知，进程的创建和调度都是有一定消耗的，而且进程的数量也不是无限的。所以，基于cgi模式运行的网站通常不能同时接受大量请求，否则每个请求生成一个子进程，就有可能把服务器挤爆。于是后来就有了fastcgi，fastcgi进程可以将自己一直运行在后台，并通过fastcgi协议接受数据包，执行后返回结果，但自身并不退出。
php有一个叫php-cgi的sapi，php-cgi有两个功能，一是提供cgi方式的交互，二是提供fastcgi方式的交互。也就说，我们可以像perl一样，让web容器直接fork一个php-cgi进程执行某脚本；也可以在后台运行 php-cgi -b .0.0.1: （php-cgi作为fastcgi的管理器），并让web容器用fastcgi协议和交互。
那我之前说的fpm又是什么呢？为什么php有两个fastcgi管理器？php确实有两个fastcgi管理器，php-cgi可以以fastcgi模式运行，fpm也是以fastcgi模式运行。但fpm是php在5.3版本以后引入的，是一个更高效的fastcgi管理器，其诸多优点我就不多说了，可以自己去翻翻源码。因为fpm优点更多，所以现在越来越多的web应用使用php-fpm去运行php。
回到本漏洞。CVE--就是php-cgi这个sapi出现的漏洞，我上面介绍了php-cgi提供的两种运行方式：cgi和fastcgi，本漏洞只出现在以cgi模式运行的php中。
这个漏洞简单来说，就是用户请求的querystring被作为了php-cgi的参数，最终导致了一系列结果。
探究一下原理， RFC 中规定，当querystring中不包含没有解码的 = 号的情况下，要将querystring作为cgi的参数传入。所以，Apache服务器按要求实现了这个功能。
但PHP并没有注意到RFC的这一个规则，也许是曾经注意并处理了，处理方法就是web上下文中不允许传入参数。但在年的时候某个开发者发表过这么一段言论：
显然，这位开发者是为了方便使用类似 #!/usr/local/bin/php-cgi -d include_path=/path 的写法来进行测试，认为不应该限制php-cgi接受命令行参数，而且这个功能不和其他代码有任何冲突。
于是， if(!cgi) getopt(...) 被删掉了。
但显然，根据RFC中对于command line的说明，命令行参数不光可以通过 #!/usr/local/bin/php-cgi -d include_path=/path 的方式传入php-cgi，更可以通过querystring的方式传入。
这就是本漏洞的历史成因。
那么，可控命令行参数，能做些什么事。
通过阅读源码，我发现cgi模式下有如下一些参数可用：
-c 指定php.ini文件的位置-n 不要加载php.ini文件 -d 指定配置项 -b 启动fastcgi进程 -s 显示文件源码 -T 执行指定次该文件 -h 和 -&#; 显示帮助
最简单的利用方式，当然就是 -s ，可以直接显示源码：
但阅读过我写的fastcgi那篇文章的同学应该很快就想到了一个更好的利用方法：通过使用 -d 指定 auto_prepend_file 来制造任意文件读取漏洞，执行任意代码：
注意，空格用 + 或 % 代替， = 用url编码代替。
这个漏洞被爆出来以后，PHP官方对其进行了修补，发布了新版本5.4.2及5.3.，但这个修复是不完全的，可以被绕过，进而衍生出CVE--漏洞。
PHP的修复方法是对 - 进行了检查：
可见，获取querystring后进行解码，如果第一个字符是 - 则设置skip_getopt，也就是不要获取命令行参数。
这个修复方法不安全的地方在于，如果运维对php-cgi进行了一层封装的情况下：
通过使用空白符加 - 的方式，也能传入参数。这时候querystring的第一个字符就是空白符而不是 - 了，绕过了上述检查。
于是，php5.4.3和php5.3.中继续进行修改:
先跳过所有空白符（小于等于空格的所有字符），再判断第一个字符是否是 - 。
这个漏洞在当年的影响应该说中等。因为PHP-CGI这个SAPI在漏洞出现的时间点，因为其性能等问题，已经在慢慢退出历史舞台了。但考虑到PHP这个在Web领域举足轻重的语言，跨越多年，用量巨大，很多老的设备、服务器仍在运行有漏洞的版本和PHP-CGI，所以影响也不能低估。
不过，在年的今天，我分析这个漏洞当然已经不能谈影响了，只是其思路确实比较有意思，又让我领会了一次阅读RFC的重要性。
自制PHP框架之路由与控制器 我们为什么要使用路由？原因1：一个更漂亮的URI1.URI的改进刚刚开始学PHP时，我们一定写过blog.phpid=1之类的URI，使用GET方式获取参数。这样的URI有两个
自制PHP框架之模型与数据库 什么是模型？我们的WEB系统一定会和各种数据打交道，实际开发过程中，往往一个类对应了关系数据库的一张或多张数据表，这里就会出现两个问题。1.
自制PHP框架之设计模式 为什么要使用设计模式？设计模式，我的理解是为了达到可复用这个目标，而设计的一套相互协作的类。感兴趣的读者可以阅读《DesignPatterns:ElementsofReus
标签: phpcgi远程代码执行漏洞
本文链接地址:https://www.jiuchutong.com/biancheng/290931.html 转载请保留说明！
