当时楼主正准备收拾东西回家，看到这个新闻心里一惊：失传江湖多年的0字符截断上传漏洞又重现了？而且还影响这么多版本！如果漏洞属实，看来今晚又要通宵打补丁了啊。
不过经过简单分析后，发现漏洞的利用条件相当苛刻（很多人好奇到底有多苛刻），楼主简单记录自己的分析过程和大家分享一下，如有不当，请多多指正。
一、漏洞概述
漏洞报告者说php的上传函数 move_uploaded_file的目的路径参数可以使用空字符截断，绕过jpg，png上传类型的检测，从而导致任意文件上传。报告者给出的测试EXP：
move_uploaded_file($_FILES['x']['tmp_name'],"/tmp/test.phpx00.jpg")
按照漏洞报告者的描述 5.3 以后版本都受影响（https://bugs.php.net/bug.php?id=69207）
二、漏洞测试
为验证漏洞有效性楼主搭建一个测试环境，版本 5.3.6，构造测试代码如下：
上传前台页面upload.htm:
上传处理脚本upload.php
测试上传upload.php始终返回失败false
于是换了一个版本5.3.29，依旧未测试成功，难道是我测试的方法不对，那就看一下源码吧。
三、漏洞调试
move_uploaded_file的代码实现在 ext/standard/basic_functions.c 文件，关键代码：
代码中有几处return false的逻辑，那么测试不成功肯定是命中了其中的一个逻辑。
楼主使用最原始的打log方法来调试，确认测试代码被上述标红代码过滤了，于是查看打印出来strlen(new_path) 和 new_path_len的值 —— 分别是19 和 23。
new_path 是路径名字符串“/tmp/whoisdashuaigex00jpg”的长度，由于strlen计算到空字符处x00结束，因此长度19可以理解。
那么为什么new_path_len是23呢？
PHP语言中所有的变量类型都保存在一个如下的结构体中，new_path_len对应标红的len。这里的len是一个二进制长度，不会遇到空字符结束所以长度为23。所以测试demo使用 在这里长度不等一直返回失败。
那测试成功的又是什么情况呢，组里另外一位同事发来消息说在5.6.6版本可测试成功，打开5.6.6漏洞代码处一看震惊了，5.6.6代码如下：
原来在高版本（受影响版本中），PHP把长度比较的安全检查逻辑给去掉了，导致了漏洞的发生，不知道这段代码是哪个开发者更新的，什么仇什么怨。
四、漏洞利用条件
漏洞利用需要控制第二个参数（目标路径），比如：
但是，实际在开发场景中，目标路径一般是程序自己生成的（避免同名文件覆盖的情况），就算退一步，程序猿同学想取原来的文件名，往往也习惯用$_FILES变量取文件名。
而$_FILES变量中如果加入 字符截断，却又不影响程序逻辑：
提交a.php jpg 和 a.php 是等价的。
测试方法如下：
上传抓包修改name为a.php jpg（ 是nul字符），可以看到$_FILES['xx']['name']存储的字符串是a.php，不会包含 截断之后的字符，因此并不影响代码的验证逻辑。
但是如果通过$_REQUEST方式获取的，则可能出现扩展名期望值不一致的情况，造成“任意文件上传”。
五、总结
1、漏洞影响版本必须在5.4.x<= 5.4.39, 5.5.x<= 5.5.23, 5.6.x <= 5.6.7，详见CVE公告：https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2348
2、漏洞利用条件苛刻，与实际业务书写代码习惯有较大的差异，因此风险较低
行为仓促，如有不当请指正。
摘自：TSRC