Lucene search

K
myhack58佚名MYHACK58:62201787046
HistoryJun 15, 2017 - 12:00 a.m.

Apache Commons Fileupload 1.3.1 DOS(CVE-2016-3092)-vulnerability warning-the black bar safety net

2017-06-1500:00:00
佚名
www.myhack58.com
544

7.5 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

7.8 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

COMPLETE

AV:N/AC:L/Au:N/C:N/I:N/A:C

0.043 Low

EPSS

Percentile

91.3%

Last year the commons-fileupload official announcements Commons Fileupload of a security vulnerability CVE-2016-3092, in the Commons FileUpload 1.3.2 repair. <http://commons.apache.org/proper/commons-fileupload/security-reports.html&gt; because at that time the security components use the Commons FileUpload 1.3.1 release, so with a bit of this vulnerability. Shortly before seeing the Prophet community@offline small octopus dumplings, for this vulnerability the vulnerability is analysed only know CVE-2016-3092 vulnerability reason is that when the boundary is too long,BufSize length is insufficient,significantly reducing the performance and code complexity of the algorithm. The following was the follow-up process.

##Vulnerability:## program to use the Commons Fileupload 1.3.1 components, a malicious user can send a carefully constructed request to make the server a denial of service. File upload when modify boundary of length close to 4096 bytes,the server will take more time than the boundray is a few dozen bytes. Later after comparison found boundray size close to 4096 when the Commons FileUpload 1.3.1 and Commons FileUpload 1.3.2 version is not much different, when boundray is much larger than the 4096 when the Commons FileUpload 1.3.1 performance problems occur.

##Vulnerability:## diff1 try to repair the large boundray problems <https://github.com/apache/commons-fileupload/commit/612d9106bd08a3c2a537badb20451121be9b64cf&gt;! [](/Article/UploadPic/2017-6/2017615112226546. png)

This from the repair results, Commons FileUpload 1.3.2 increasing the bufSize the length of the, also confirmed, CVE-201 6-3092 vulnerability reason is that when the boundary is too long, BufSize length is insufficient, significantly reducing the performance and code complexity of the algorithm for the conclusion.

First do not discuss vulnerability, from the code perspective, commons-fileupload1. 3. 1 version is to put these assignment logic in the security check logic before the code is as follows:

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 {

[1] [2] [3] next

7.5 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

HIGH

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

7.8 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

NONE

Integrity Impact

NONE

Availability Impact

COMPLETE

AV:N/AC:L/Au:N/C:N/I:N/A:C

0.043 Low

EPSS

Percentile

91.3%

Related for MYHACK58:62201787046