Tomcat Security Constraint Bypass CVE-2017-5664 analysis-vulnerability warning-the black bar safety net

1. DefaultServlet role
I’m in front of the public, the article said, the JspServlet’s role is to process the jsp and jspx files a request, then the non-jsp jspx is by the DefaultServlet to handle it different, but because it is a tasteless, not discussed here so much, here we simply believe that the static files will be cross-linked by the DefaultServlet to handle it.
2. DefaultServlet can handle PUT or DELETE request, provided the request is readOnly to false, but the default value is true. In order to trigger the vulnerability 需要在conf/web.xml in the default servlet configuration add the following configuration:

readonly

false
3. In the WEB application web.xml add the following configuration for a WEB application custom 404 error page:
404
/404.html
When the DefaultServlet readOnly to false, we will open the DefaultServlet handle a PUT request function, we can to the target to upload the file. The request must reach the DefaultServlet to the PUT operation, which means that we can upload the type of file is restricted, for example, by default we can upload a jsp or jspx.
For example, the following command:

curl-i-T aaa. jsp http://localhost:8080/CVE-2017-5664/aaa.jsp
Our intention is to aaa. jsp PUT to the target server, save it as aaa. jsp. Here we used the path is

http://localhost:8080/CVE-2017-5664/aaa.jsp
This request will be JspServlet processing, rather than being DefaultServlet processing. JspServlet is not processing the PUT request that can be understood as the JspServlet will be all the requests as the GET to handle., the Which is why we can’t upload jsp jspx file reasons. We can only upload other types of files, and this is usually a static file.
For example, in the readOnly to false, 我们可以通过如下命令上传aaa.txt

curl-i-T aaa.txt http://localhost:8080/CVE-2017-5664/aaa.txt
Because of the above request will be DefaultServlet processing, so the PUT operation will succeed.
Official for the CVE DESCRIPTION is as follows:
The error pagemechanism of the Java Servlet Specification requires that, when an error occursand an error page is configured for the error that occurred, the originalrequest and response are forwarded to the error page. This means that therequest is presented to the error page with the original HTTP method.
If the error page is a static file, the expected behaviour is to serve the content of the file as if processing a GET request,regardless of the actual HTTP method. Tomcat’s Default Servlet did not do this. Depending on the original request this could lead to unexpected and undesirableresults for static error pages including, if the DefaultServlet is configuredto permit writes, the replacement or removal of the custom error page.
The effect is:
The Java Servlet specification requirements, when access of resources occurs such as 404 or 500 or the like of the error, and while the service side configuration of the corresponding error page, the original request should be forward to an error page.
When the error page is a static file, the correct approach should be to ignore the original request’s HTTP METHOD, direct image processing GET request as to the client returns a static error page content. However Tomcat’s Default Servlet is not doing so. If the DefaultServlet configuration of the readOnly to false, then a malicious request it is possible to remove or replace the error page file.
I’m here to say directly about how to achieve the official said “replacement ofthe custom error page”.

curl-i-T aaa. jsp http://localhost:8080/CVE-2017-5664/aaa.jsp
It says this command is not uploaded aaa. the jsp because the request is JspServlet processing. So here a direct simple way Tomcat after receiving the PUT request is how to deal with, and here it does not analyze the code.
It is assumed that the server is not the presence of aaa. jsp. JspServlet receipt of this request, found not to exist/aaa. the jsp corresponding to the JspServletWrapper, while the connecting/aaa. jsp this file also does not exist, then it should be returned to the client 404 in.
But because we in the above to the application configure a custom 404 page:/404.html so the original request is going forward to this /404.html the. 因为/404.html is a static file, it will be by the DefaultServlet to deal with here is the key, also explains why the error page must be a static file, because the only static file request will go to the DefaultServlet, the DefaultServlet discovery request is a PUT request 所以直接利用从客户端传来的文件数据将/404.html rewrite.
Examples
The original 404.html as follows:
! [](/Article/UploadPic/2017-7/2017727184445284. png? www. myhack58. com)
To access a non-existent 111. jsp, returns a 404.html content:
! [](/Article/UploadPic/2017-7/2017727184445490. png? www. myhack58. com)
Now directly PUT to a non-existent jsp file, there is also to 111. jsp, for example:
! [](/Article/UploadPic/2017-7/2017727184445403. png? www. myhack58. com)
Then go to view 404.html content:
! [](/Article/UploadPic/2017-7/2017727184445449. png? www. myhack58. com)
The official patch is to let the DefaultServlet rewrite inherited from the parent class of the service method, when a discovery request is due to errors forwarded over the directly as the GET to deal with:
! [](/Article/UploadPic/2017-7/2017727184445563. png? www. myhack58. com)
Summary
Tasteless, low risk.
The trigger requirements
Need DefaultServlet readonly value is false, default is true.
The requirements of service-end configure a custom static error page, and the client can trigger the appropriate error to make the request is forwarded to the error page.

Repair way
Upgrade
If not necessary, do not change the DefaultServlet readonly default value
Do not use static files as error pages, you can use the jsp file.