PHP Multipart/form-data remote DOS 防御方案研究

CVE-2015-4024漏洞，据发布时间过去了好几天，我来总结一下。

这个的DOS漏洞炒得很火，百度安全攻防实验室的小伙伴也很给力。我个人认为漏洞的影响确实很大，毕竟对于一个web应用，拒绝服务攻击可以说是杀死它最简单的方法。这样大张旗鼓地说也很必要，也是一种加速杀死php 5.2/5.3的方式。

前不久才说了要赶紧弃用php 5.2/5.3事情，这次出了这么大的漏洞，很多用5.3的同学就着急了，各种求5.3的patch。

漏洞原理在drops的中文文章中（http://drops.wooyun.org/papers/6077）已经解释过了，是由于php没有妥善处理multipart/form-data请求的body part请求头，对于换行内容多次重新申请内存，导致耗尽CPU资源，拒绝服务计算机。

其实在C语言里会常常遇到这种现象，当你不知道某个buffer究竟要申请多长空间时，就必须先申请部分资源，再根据用户输入多次重新申请内存。而如果不加限制的话，就可能导致耗尽系统资源的问题。

Ryat哥很给力地带来了PHP低版本一个民间patch：https://gist.github.com/chtg/4aecda8ae4928f8fb1b2，方式就是限制换行次数，大于100的话就不继续分配内存了：

--- a/php-5.3.29/main/rfc1867.c

+++ b/php-5.3.29-fixed/main/rfc1867.c

@@ -464,6 +464,8 @@ static int multipart_buffer_headers(multipart_buffer *self, zend_llist *header T

char *line;

mime_header_entry prev_entry, entry;

int prev_len, cur_len;

+ int newlines = 0;

+ long upload_max_newlines = 100;

/* didn't find boundary, abort */

if (!find_boundary(self, self->boundary TSRMLS_CC)) {

@@ -489,6 +491,7 @@ static int multipart_buffer_headers(multipart_buffer *self, zend_llist *header T

entry.value = estrdup(value);

entry.key = estrdup(key);

+ newlines = 0;

} else if (zend_llist_count(header)) { /* If no ':' on the line, add to previous line */

@@ -501,6 +504,10 @@ static int multipart_buffer_headers(multipart_buffer *self, zend_llist *header T

entry.value[cur_len + prev_len] = '';

entry.key = estrdup(prev_entry.key);

+ newlines++;

+ if (newlines > upload_max_newlines) {

+ return 0;

+ }

zend_llist_remove_tail(header);

} else {

当然打patch的方法，阿里云安全的同学也给出了：http://weibo.com/p/1001603844614980257697。简单说就是打补丁后，重现编译，再打包。

对于使用apt-get安装php的同学，道理也类似，一个rpm一个deb罢了。

或者，像我一样。上篇文章里我也说了，我php是用apt-get直接安装的，嫌麻烦。不过这次事情过后，我觉得万事还是需要动手，否则总是心里虚虚的。

于是我还是下载了最新源码，重新将php编译了一遍（过程大概就是这篇文章类似：http://www.jb51.net/article/42719.htm ），中间遇到的有些艰难险苦就不多说了。像我这种apt-get后再手工编译的同学，可能不知道编译选项是什么。而php的话还是很简单的，phpinfo的第三行其实就告诉我们了：

（ps. 见上图，作为一个在May 20这天还在编译php的同学，我也是很拼的）

而还是有好些同学并不会编译php，要不就是嫌麻烦，是用一键安装包安装的。那我就没法了。但如果你有装过ngx_lua_waf或modsecurity的话，可以自己编写lua脚本来临时防御漏洞。

我给出我lua waf一些代码片段吧：

postdata = split(postdata, boundary)

local i = 1

while i < #postdata do

local lines = split(postdata[i], "rnrn")

if #lines[0] == nil or lines[1] == nil or (not string.find(lines[0], "Content%-Disposition")) then

ngx.exit(445)

return true

end

----defense CVE-2015-4024

local form_data_header = split(lines[0], "n")

if #form_data_header > 10 then

ngx.exit(447)

return true

end

----defense CVE-2015-4024

local key = string.gmatch(lines[0], "%sname="(.+)"")()

local val = string.gmatch(lines[0], "filename="(.+)"")()

核心思路就是用rnrn将form-data的body part分成header和body，header再用n分割，如果数量大于10的话就直接拦截下来，返回447错误。通过这样的方式，临时抵御这次的DOS漏洞，nginx层拦截后这个数据包将不会被发送给php，所以也就不会造成DOS了。

效果如下。正常情况下上传不拦截：

当header行数超过10行，返回447错误：

但我的建议还是从根源上修补漏洞（即升级PHP到最新版本），而不是通过WAF来拦截。WAF是一个渔网，能网住大多数的鱼，但总有些小鱼是可以逃走的。况且渔网时不时地还会破几个洞，导致我们的防御形同虚设。

说些后话吧，百度安全实验室在我印象里一直很踏实，大牛很多也很低调，这次的漏洞也着实让我们看到了他们的实力。

不得不说，有时候有专业“运营”的安全团队，真还不如踏实做事的安全团队。多挖点国际漏洞增加的影响力，往往比让几个妹纸常常做些炒作、活动来的影响力要好很多。

本文始发于微信公众号（代码审计）：PHP Multipart/form-data remote DOS 防御方案研究