apache tomcat文件上传组件导致apache dos漏洞

发布时间:2016-12-8 17:49:40 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"apache tomcat文件上传组件导致apache dos漏洞",主要涉及到apache tomcat文件上传组件导致apache dos漏洞方面的内容,对于apache tomcat文件上传组件导致apache dos漏洞感兴趣的同学可以参考一下。

我们现在的文件上传基本上都是基于http协议的,rfc1867 (http://www.ietf.org/rfc/rfc1867.txt) 为 http 协议添加了文件上传功能,可以根据以下格式上传文件内容: POST /xxxxx/yyyyy HTTP/1.1 Accept: text/plain, */* Accept-Language: zh-cn Host:xx.xx.xx.xx:80 Content-Type:multipart/form-data;boundary=1234 User-Agent: Mozilla/4.0 (compatible;OpenOffice.org) Content-Length: 424 Connection: Keep-Alive Content-Disposition: form-data;name="file"; filename="foo.tab" Content-Type: text/whatever This is the content of the file --1234 Content-Disposition: form-data;name="field" fieldValue --1234 Content-Disposition: form-data;name="multi" value1 --1234 Content-Disposition: form-data;name="multi" value2 --1234-- 每个字段用“--boundary”分隔,最后一个”--boundary--”表示结束。 这里要注意区分一个段的标识是2个dash字符(--)+boundary的字节内容+回车换行(4个字节)。 commons-uploads 上传组件的原理是将以上一个或多个文件转换成FileItem列表,而FileItem是由FileuploadBase类的私有的FileItemIteratorImpl类内部通过 MultipartStream封装和解析request得到的。 安全漏洞就出在FileItemIteratorImp在创建MultipartStream时不严谨导致的。 MultipartStream的构造方法本来是由(InputStreaminput,byte[] boundary,int bufSize,ProgressNotifier pNotifier)构成, 但是FileItemIteratorImp在构造时,图方便使用了另一个简化的构造方法(InputStream input,byte[] boundary,ProgressNotifier pNotifier); 少了的bufSize在multipartStream内部,决定了每次处理请求时缓冲区的大小,当然了,这里申请的缓冲区内容也会包含boundary的内容,比如示例中的1234。 默认bufSize为4096,那么如果boundary内容大于4096会发生什么?举个例子,假设畸形的 boundary 内容转换成byte数组大小是5048,这时我们来看看multipartStream内部发生了什么。 在简化的构造方法中,这时,multipartStream类将boundary的内容填满buffer内容,这本身不会造成缓冲区溢出,但是,因为boundary字节长度大于缓冲区长度,导致boundary内容被截断。 OK,问题来了,在组件继续往下解析时,在fileuploadBase类中私有方法findnextItem 时重新实现的input stream在执行read方法时,调用了makeAvailable方法, 此方法内部通过一个循环查找buffer内容中的boundary内容,但是因为缓冲区中boundary内容不完整,导致循环条件无法结束,死循环产生了。o(╯□╰)o OK,处理此线程的cpu开始忙起来了,多执行几次,比如5次,机器所有的cpu都要开始进行无法完成的工作了,正常的请求将无法处理。 知道问题了,怎么解决?把缓存的buffer size设置成boundary的大小可以吗?回答是NO!刚才前面说了区分一个段的标识,是2个dash字符+boundary内容+回车换行。 到这里,内心就敞亮了,buffer size的大小起码要设置成boundary的大小+6个byte,这样,循环才能正常结束。 确实是个埋藏的很深的隐患。 ———— 升级后的1.3.1的处理方法,当boundary的大小超过4096时,直接抛出异常。这种Fail Fast的处理策略真正高效,因为只有“好事者”才会设置如此大的boundary的内容。

上一篇:Object-C中的字符串对象2-可变字符串
下一篇:eclipse启动报错 “failed to create the java virtual machine”解决办法

相关文章

相关评论