Tomcat information disclosure Vulnerability(CVE-2017-12616 )analysis

Several recent Tomcat CVE

• CVE-2017-5664 Tomcat Security Constraint Bypass
• CVE-2017-12615 remote code execution vulnerability
• CVE-2017-12616 information disclosure vulnerability

Common

Is tasteless With JspServlet and DefaultServlet about the system.

CVE-2017-12615 this remote code execution are everywhere, and it seems like no one is watching CVE-2017-12616 cause JSP source code leakage problems. Here simply write about it.

CVE-2017-12616

Requirements

Target the use of VirtualDirContext to mount the virtual directory. Mount the virtual catalog of the demand should still have some, so should be larger than the opening and PUT the probability to be larger, but is also tasteless.

A brief analysis

To cause Jsp source code disclosure, definitely need to let the DefaultServlet to handle jsp requests. Tomcat use similar JNDI way to manage Web resources, JSP, static file, Class, etc. By default, resources by FileDirContext to manage. And the use of VirtualDirContext mount the virtual catalog, is by the VirtualDirContext to manage.

Through the similar to CVE-2017-12615 use way to access the virtual directory of resources, allowing the request by the DefaultServlet processing, the Tomcat from VirtualDirContext management of resources to obtain access to the jsp files through the doLookup method, directly to the content returned, resulting in source code disclosure.

Why only the virtual directory for the existence of this vulnerability? Because of the non-virtual directory default by FileDirContext management. FileDirContext in the presence of a named file check method. `` protected File file(String name) {

File file = new File(base, name);
if (file. the exists() && file. the canRead()) {

 if (allowLinking)
 return file;

 // Check that this file belongs to our root path
 String canPath = null;
 try {
 canPath = file. getCanonicalPath();
 } catch (IOException e) {
 // Ignore
}
 if (canPath == null)
 return null;

 // Check to see if going outside of the web application root
 if (! canPath. startsWith(absoluteBase)) {
 return null;
}

 // Case sensitivity check - this is now always done
 String fileAbsPath = file. getAbsolutePath();
 if (fileAbsPath. endsWith("."))
 fileAbsPath = fileAbsPath + "/";
 String absPath = normalize(fileAbsPath);
 canPath = normalize(canPath);
 if ((absoluteBase. length() < absPath. length())
 && (absoluteBase. length() < canPath. length())) {
 absPath = absPath. substring(absoluteBase. length() + 1);
 if (absPath. equals(""))
 absPath = "/";
 canPath = canPath. substring(absoluteBase. length() + 1);
 if (canPath. equals(""))
 canPath = "/";
 if (! canPath. equals(absPath))
 return null;
}

} else {
 return null;
}
return file;

} ``

This method can not prevent /a. jsp/ this URL, but DefaultServlet then have a check at the end of the/, leading to / Can’t be used.

And the new version of the fix mode is also the code for the small-scale reconstruction, the above method of checking the disassembly to called the validate method, and re-wrote VirtualDirContext in a lot of method, call the validate access to the file to be checked.

Use

With CVE-2017-12615 similar, to achieve the view Jsp file source code of the effect.