一、漏洞概述 漏洞报告者说php的上传函数 move_uploaded_file的目的路径参数可以使用空字符截断,绕过jpg,png上传类型的检测,从而导致任意文件上传。报告者给出的测试EXP: move_uploaded_file($_FILES['x']['tmp_name'],"/tmp/test.php\x00.jpg") 二、漏洞测试 为验证漏洞有效性楼主搭建一个测试环境,版本 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/whoisdashuaige\x00jpg”的长度,由于strlen计算到空字符处\x00结束,因此长度19可以理解。 那么为什么new_path_len是23呢? PHP语言中所有的变量类型都保存在一个如下的结构体中,new_path_len对应标红的len。这里的len是一个二进制长度,不会遇到空字符结束所以长度为23。所以测试demo使用\0在这里长度不等一直返回失败。 那测试成功的又是什么情况呢,组里另外一位同事发来消息说在5.6.6版本可测试成功,打开5.6.6漏洞代码处一看震惊了,5.6.6代码如下: 原来在高版本(受影响版本中),PHP把长度比较的安全检查逻辑给去掉了,导致了漏洞的发生,不知道这段代码是哪个开发者更新的,什么仇什么怨。 四、漏洞利用条件 漏洞利用需要控制第二个参数(目标路径),比如: 但是,实际在开发场景中,目标路径一般是程序自己生成的(避免同名文件覆盖的情况),就算退一步,程序猿同学想取原来的文件名,往往也习惯用$_FILES变量取文件名。 而$_FILES变量中如果加入\0字符截断,却又不影响程序逻辑: 提交a.php\0jpg 和 a.php 是等价的。 测试方法如下: 上传抓包修改name为a.php\0jpg(\0是nul字符),可以看到$_FILES['xx']['name']存储的字符串是a.php,不会包含\0截断之后的字符,因此并不影响代码的验证逻辑。 但是如果通过$_REQUEST方式获取的,则可能出现扩展名期望值不一致的情况,造成“任意文件上传”。 五、总结 2、漏洞利用条件苛刻,与实际业务书写代码习惯有较大的差异,因此风险较低
|