Apache Tomcat server vulnerable to DDOS attack, This vulnerability (CVE-2014-0050) which allows attackers to take down your Tomcat-deployed web sites and web services.
According Mark Thomas, a Project Management Committee Member and Committer in the Apache Tomcat project, This issue was reported responsibly to the Apache Software Foundation via JPCERT but an error in addressing an e-mail led to the unintended early disclosure of this issue.
It is possible to craft a malformed Content-Type header for a multipart request that causes Apache Commons FileUpload to enter an infinite loop. A malicious user could, therefore, craft a malformed request that triggered a denial of service.
This issue was reported responsibly to the Apache Software Foundation via JPCERT but an error in addressing an e-mail led to the unintended early disclosure of this issue.
The fixed code has an extra “if” condition (line number 330) that validates the length of the multipart boundary to be shorter than 4091 characters, raising an exception if that’s not the case. The calculation is as follows:
boundary.length > bufSize – 1 – BOUNDARY_PREFIX.length = 4096 – 1 – 4 = 4091
Multipart is often used in HTTP for the purpose of uploading files. When your application needs to send a file to the server that has binary data, or data that might interfere with the structure of the HTTP message.
it is possible to use a multipart content-type and setup a magic line to separate between values. This magic line is the boundary value and should be random enough that it doesn’t appear in the actual content sent.
Apache Tomcat installed and try to send more than 4091 characters in the boundary field to the Apache Tomcat Manager application.
When you are writing loops, check your boundaries. When you are writing endless loops, check your boundaries even more carefully.
While parsing the multipart message, the following “for” loop is used by the MultipartStream class:
The innocent-looking “for” loop above is an endless loop. It is “family related” to the famous “while(true)” loop. The developer’s intention was to exit this loop either by raising an exception (line 1003) or by returning a value (line 1014), unfortunately when the boundary is longer than 4091 characters and the body is longer than 4096 characters, neither would ever occur.
How Do you know, your vulnerable?
1) You are using Apache Tomcat 7.0-7.0.50 or 8.0-8.0.1 and your code utilizes Servlet 3.0 specifications (for example, “request.getPart” or “request.getParts” methods)
2) You are using Apache Commons FileUpload < 1.3.1
To be honest, these libraries are so commonly used that you might not even know that your site is vulnerable.
I wrote a small Ruby proof-of-concept exploit to help administrators try and recreate the Denial-of-Service state on QA and staging environments. This can help administrators and developers understand if a certain URL is vulnerable to the attack (but needs to be tested on all URLs).
The tool can also assist white-hat security professionals that are required to confirm the vulnerability throughout an engagement.
Download CVE-2014-0050
References:
http://markmail.org/message/kpfl7ax4el2owb3o
http://tomcat.apache.org/security-8.html
http://tomcat.apache.org/security-7.html
http://blog.spiderlabs.com/
According Mark Thomas, a Project Management Committee Member and Committer in the Apache Tomcat project, This issue was reported responsibly to the Apache Software Foundation via JPCERT but an error in addressing an e-mail led to the unintended early disclosure of this issue.
It is possible to craft a malformed Content-Type header for a multipart request that causes Apache Commons FileUpload to enter an infinite loop. A malicious user could, therefore, craft a malformed request that triggered a denial of service.
This issue was reported responsibly to the Apache Software Foundation via JPCERT but an error in addressing an e-mail led to the unintended early disclosure of this issue.
The fixed code has an extra “if” condition (line number 330) that validates the length of the multipart boundary to be shorter than 4091 characters, raising an exception if that’s not the case. The calculation is as follows:
boundary.length > bufSize – 1 – BOUNDARY_PREFIX.length = 4096 – 1 – 4 = 4091
Multipart is often used in HTTP for the purpose of uploading files. When your application needs to send a file to the server that has binary data, or data that might interfere with the structure of the HTTP message.
it is possible to use a multipart content-type and setup a magic line to separate between values. This magic line is the boundary value and should be random enough that it doesn’t appear in the actual content sent.
Apache Tomcat installed and try to send more than 4091 characters in the boundary field to the Apache Tomcat Manager application.
When you are writing loops, check your boundaries. When you are writing endless loops, check your boundaries even more carefully.
While parsing the multipart message, the following “for” loop is used by the MultipartStream class:
The innocent-looking “for” loop above is an endless loop. It is “family related” to the famous “while(true)” loop. The developer’s intention was to exit this loop either by raising an exception (line 1003) or by returning a value (line 1014), unfortunately when the boundary is longer than 4091 characters and the body is longer than 4096 characters, neither would ever occur.
How Do you know, your vulnerable?
1) You are using Apache Tomcat 7.0-7.0.50 or 8.0-8.0.1 and your code utilizes Servlet 3.0 specifications (for example, “request.getPart” or “request.getParts” methods)
2) You are using Apache Commons FileUpload < 1.3.1
To be honest, these libraries are so commonly used that you might not even know that your site is vulnerable.
I wrote a small Ruby proof-of-concept exploit to help administrators try and recreate the Denial-of-Service state on QA and staging environments. This can help administrators and developers understand if a certain URL is vulnerable to the attack (but needs to be tested on all URLs).
The tool can also assist white-hat security professionals that are required to confirm the vulnerability throughout an engagement.
Download CVE-2014-0050
References:
http://markmail.org/message/kpfl7ax4el2owb3o
http://tomcat.apache.org/security-8.html
http://tomcat.apache.org/security-7.html
http://blog.spiderlabs.com/
No comments:
Post a Comment