我要评论通过前两篇文章的铺垫，现在我们可以了解 cve-2024-4577这个漏洞的原理
漏洞原理
cve-2024-4577是cve-2012-1823这个老漏洞的绕过，php cgi的老漏洞至今已经12年，具体可以参考我的另一个文档
简单来说，就是使用cgi模式运行的php，根据rfc3875的规定，apache会将请求的query_string作为命令行参数交给php-cgi执行。攻击者利用这个特性，就可以-d选项修改php的配置项，最后执行任意代码。
文章的最后，我也提到了当时php官方修复了两次才完成的补丁：
修复方式就是在获取到query_string后，检查其开头是否是横线（-），如果是-，则跳过后面对参数的解析。而@orange 这次发现的cve-2024-4577实际上就是横线检查的绕过，来说下原理。
在windows中，如果当前系统的字符集（也被称为代码页，code page）非unicode编码，在main()函数获取argv的时候，会自动执行编码的转换，其中就会涉及到所谓的best-fit。cp936
gbk
best-fit是一种字符映射策略，用以解决源代码页中的字符在目标代码页中没有直接等价物时的问题。在将unicode代码页中字符转换成非unicode代码页字符时，如果无法找到对应的字符，就会按照best-fit预定义的一个转换表进行转换。
比如，gbk编码（cp936）的best-fit mapping转换表是：https://www.unicode.org/public/mappings/vendors/micsft/windowsbestfit/bestfit936.txt
其中有一些有趣的字符转换，比如0xaa在转换后会变成a，0xb2在转换后会变成2，0xad在转换后会变成-。
所以，这里我们就可以利用best-fit这个特性，使用%ad来代替横线-。php在执行上述检查的时候，会认为命令行的第一个字符是0xad；实际上main()函数的argv的第一个字符已经被windows按照best-fit mapping转换成-。
本质来说，这仍然是一个利用解析差异绕过防御措施的案例。
什么情况下才会使用best-bit转换字符串？
我们可以编写下面这个简单的python代码来复现best-fit这个trick：
os.system("php \xadh")
虽然传入的是\xad，但实际最后执行成功。
但我们多测试几次就会发现，并不是所有程序的所有参数都会进行best-bit的转换，我们测试下面几个命令：
php -h => php \xadh => 成功
php -v => php \xadv => 出错
python -h => python \xadh => 出错
arp -h => arp \xadh => 成功
有的成功，有的出错。这是为什么呢？
阅读php代码就会发现，有一部分选项是直接使用的main()函数的argv，另一部分选项是从windows api getcommandlinew()函数获取。由getcommandlinew()获取的这部分参数仍然保持原样，没有转换成横线，最后无法正确执行。
xampp为什么可以被利用？
orange在文章中提到，xampp默认配置就可以被利用。最初读到这里的时候，我会以为xampp是以php-cgi模式运行的php服务器，但下载安装xampp后我发现，php实际上是以apache 2.0 handler的方式运行。
这时候就非常有趣了，为什么xampp仍然可以在不修改任何配置文件的情况下直接利用呢？为什么很多人在实际测试中会遇到500错误呢？
这实际上是php没有修复的另一个安全机制bypass
比如，默认情况下我们需要将php解释器放在cgi-bin目录下，这样用户通过访问/cgi-bin/php/dir/script.php，即可执行/dir/script.php。
这个操作是很危险的，所以php增加了如下配置：cgi.force_redirect=1，开启了这个选项（默认开启）以后，只有经过了重定向规则请求才能执行。
apache在重定向（rewrite）的时候，会增加一个名为redirect_status的环境变量，cgi.force_redirect就是依赖这个环境变量，来判断是否经历了重定向。
如果非apache服务器，我们就需要设置一下cgi.redirect_status_env，来指定php判断请求是否经历重定向的条件。
xampp默认使用的sapi
我们下载xampp后，查看phpinfo可以发现，其运行php的模式是“apache 2.0 handler”。在这个模式下，php会被编译成apache的一个模块（dll动态链接库）并由apache来调用执行。
我们在apache/conf/extra/httpd-xampp.conf中可以找到相关的配置：
可见，这里所有的.php后缀文件会被交给php8apache2_4.dll来执行，这和php cgi是没有任何关系的。
如何正常配置使用php cgi？
思考一个问题，如果我们需要正常配置一个使用php cgi解析php的apache服务器，应该如何编写配置文件呢？
如果是部署基于脚本的cgi服务器，我们需要将可执行文件放置在某个目录下，比如/cgi-bin/hello.cgi。这个hello.cgi脚本的第一行是“shebang”，用以指定当前脚本的解释器，比如 # !/bin/bash
-
设置 php 文件的 shebang 行和 content-type 头
在每个 php 脚本的开头添加 shebang 行和
content-type头。例如，/cgi-bin/hello.cgi文件内容如下：其中，
#!/usr/bin/php是 shebang 行，用于指定 php 解释器的路径。 -
设置文件权限
确保 php 文件具有执行权限，使其可以作为 cgi 脚本运行：
-
测试脚本
通过浏览器访问该脚本。例如，如果 cgi 脚本路径是
/cgi-bin/hello.cgi，则访问http://yourdomain.com/cgi-bin/hello.cgi。
事实上几乎没有php应用会这么编写代码，相比于这种将脚本直接作为可执行文件的方法，php另辟蹊径，专门设计了一个sapi就叫php-cgi。
调用php-cgi执行一个php文件时，它会负责输出“content-type”头。比如执行echo '<?php echo 123;' | php-cgi
所以，类似于hello.cgi，我们也可以直接将php-cgi这个可执行文件映射到/cgi-bin/目录下，然后再使用apache的action指令，将php相关请求“重定向”到php-cgi上，最后执行php代码。
此时配置文件如下：
scriptalias /php-cgi/ "/program/xampp/xampp/php/"
<directory "/program/xampp/xampp/htdocs">
addhandler application/x-httpd-php .php
action application/x-httpd-php /php-cgi/php-cgi.exe
</directory>scriptalias指令的作用是将/php-cgi/路径指向/program/xampp/xampp/php/目录，
action指令的作用就是将所有对.php文件的请求都使用/php-cgi/php-cgi.exe，也就是/program/xampp/xampp/php/php-cgi.exe来执行。
apache在调用php-cgi的时候，会设置环境变量redirect_status。php-cgi为了确认这个请求确实是由action指令执行的，而不是用户直接请求的，增加了一个开关“cgi.force_redirect”，默认开启。开启这个开关的情况下，php-cgi会验证此次执行是否包含环境变量redirect_status。
xampp为什么可以被利用？
了解了php-cgi正常的部署方式，我们回来看下xampp。虽然xampp执行php时使用的是apache 2.0 handler，但它仍然给php cgi预留了一个口子，就是使用scriptalias指令把php-cgi.exe映射到了web目录下。
上述两个关键指令，xampp中使用了scriptalias指令，但是action指令被注释了
这本身也没太大问题，因为有cgi.force_redirect的限制，在没有action指令的情况下直接访问php-cgi.exe，redirect_status环境变量不会被设置。我们可以做个测试，直接请求/php-cgi/php-cgi.exe会返回500错误，查看日志会有security alert!的字眼
php-cgi.exe 接收cgi格式 -d=cgi.force_redirect=0 说明不再检测环境变量redirect_status
因为我们前面说到，对于redirect_status环境变量的限制是cgi.force_redirect这个开关来决定的。那么我们直接利用cve-2024-4577漏洞，添加-d cgi.force_redirect=0关闭这个开关，即可绕过限制了。
值得注意的是，因为在高版本php中，allow_url_include这个开关已经被废弃，所以会抛出一个警告，导致content-type头输出失败，也会返回500。网上很多人没有注意到这一点，我们需要添加一个-d error_reporting=0来规避这一点。
php没有修复的另一种cgi.force_redirect绕过
前面我们使用-d cgi.force_redirect=0关闭php的检查，实际上php中有另一个bug，也可以导致cgi.force_redirect的绕过，而且最新版本仍然没有修复
我们查看php源码sapi/cgi/cgi_main.c中对于redirect_status环境变量的检查代码：
可见，除了getenv("redirect_status")以外，还有一个getenv("http_redirect_status")，这两个环境变量都可以用于cgi.force_redirect的检查。而第二个环境变量http_redirect_status是由http_开头。
httpoxy漏洞就是因为很多http客户端会使用http_proxy环境变量的值作为代理，因为这个环境变量是http_开头，导致我们可以通过http请求头控制，造成漏洞
php这里也是一样的问题，环境变量http_redirect_status原本是为了兼容netscape，但它是由http_开头，所以用户可以直接控制。
php这里也是一样的问题，环境变量http_redirect_status原本是为了兼容netscape，但它是由http_开头，所以用户可以直接控制。
我们去掉前面poc中的-d cgi.force_redirect=0，并添加一个http头redirect-status: 1，仍然可以成功利用漏洞
虽然cve-2024-4577漏洞在最新的php版本中已经修复了，但这个环境变量http_redirect_status仍然可以导致cgi.force_redirect的绕过。
发表评论