频道栏目
首页 > 安全 > 网络安全 > 正文

Apache Commons Fileupload 1.3.1 DOS(CVE-2016-3092)

2017-06-16 09:33:52      个评论      
收藏   我要投稿

Apache Commons Fileupload 1.3.1 DOS(CVE-2016-3092),去年commons-fileupload官方公告Commons Fileupload的一个安全漏洞 CVE-2016-3092,在 Commons FileUpload 1.3.2中修复。 http://commons.apache.org/proper/commons-fileupload/security-reports.html 由于当时安全组件中使用了Commons FileUpload 1.3.1版本,所以跟了一下这个漏洞。前不久看到先知社区@离线章鱼小团子,对此漏洞漏洞进行了分析才知道CVE-2016-3092漏洞原因是当 boundary 过长时,BufSize 长度不足时,大幅降低性能(与源码算法复杂度有关)。下面是当时跟进的过程。

##漏洞原因:## 程序使用Commons Fileupload 1.3.1组件,恶意的用户可以发送精心构造的请求使服务器拒绝服务。文件上传时修改boundary的长度接近4096字节,服务器会花费更多的时间比boundray是几十个字节的时候。 后来经过对比发现boundray大小接近4096的时候Commons FileUpload 1.3.1和Commons FileUpload 1.3.2版本区别不大,当boundray远大于4096的时候Commons FileUpload 1.3.1性能会出现问题。

##漏洞原理:## diff1 尝试修复大的boundray的问题 https://github.com/apache/commons-fileupload/commit/612d9106bd08a3c2a537badb20451121be9b64cf

\

这个从修复结果看,Commons FileUpload 1.3.2增大了bufSize的长度,也证实了,CVE-201 6-3092 漏洞原因是当 boundary 过长时,BufSize 长度不足时,大幅降低性能(与源码算法复杂度有关)的结论。

先不讨论漏洞,从代码角度上来看, commons-fileupload1.3.1版本是把这些赋值逻辑放在了安全校验逻辑之前,代码如下:

this.input = input; this.bufSize = bufSize; this.buffer = new byte[bufSize]; this.notifier = pNotifier; this.boundaryLength = boundary.length + BOUNDARY_PREFIX.length; if(bufSize < this.boundaryLength + 1) { throw new IllegalArgumentException("The buffer size specified for the MultipartStream is too small");} else {

它导致的问题就是把外界的没有经过验证的数据直接信任的保存到了内存当中,然后在校验内存的数据是否合法,这种代码增加了安全风险,同时也增加了系统的开销。

14年Apache当时未修复CVE-2014-0050可导致死循环的问题。增加了下面的处理逻辑:

if (bufSize < this.boundaryLength + 1) { throw new IllegalArgumentException( "The buffer size specified for the MultipartStream is too small"); "The buffer size specified for the MultipartStream is too small");}

通过调试发现bufSize的值每次都是4096个字节,CVE-2016-3092攻击场景是使用多线程脚本上传文件(slow upload),当boundary远大于4096个字节的时候,在版本1.3.1程序会不断的开辟内存空间来存放boundary的内容进而导致内存的耗尽,二在版本1.3.2直接会导致异常,不会消耗太多CPU时间。当boundary.length <= bufSize - BOUNDARYPREFIX.length -1的时候,Commons FileUpload 1.3.1和Commons FileUpload 1.3.2都可以正常执行,但是危害相对就小很多了。

测试的方法构造一个boundary大小为1000000字节的数据包,循环发送500次请求,测试结果: Commons FileUpload 1.3.1

\

Commons FileUpload 1.3.2

\

##影响范围:## Apache Commons Fileupload 1.3 to 1.3.1 Apache Commons Fileupload 1.2 to 1.2.2 The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be affected. Apache Tomcat 9.x to 9.0.0M6 Apache Tomcat 8.x to 8.0.35 Apache Tomcat 7.x to 7.0.69 Apache Tomcat 6.x Unsupported versions of Apache Tomcat, like 5.x may also be affected. Apache Struts 2.5.x, and previous versions, which are distributing Commons FileUpload 1.3.1, or earlier versions.

Jenkins JSPWiki JXP Lucene-Solr onemind-commons Spring Stapler Struts 1 WSDL2c ##修复方案:## 方案一:升级Commons Fileupload 1.3.1版本到Commons Fileupload 1.3.2

commons-fileupload commons-fileupload 1.3.2

方案二:限制允许最大的HTTP请求报文头值maxHttpHeaderSize (http请求头信息的最大程度,超过此长度的部分不予处理。) 编辑tomcat配置文件conf/server.xml。

上一篇:数字取证技术——NTFS更改日志
下一篇:计算机防御系统的重要性 随时保障信息安全
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 |

版权所有: 88bifa.com--致力于做实用的IT技术学习网站