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> 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>! [](/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 {
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%