Bug 58999 - StringIndexOutOfBoundsException WebAppClassLoaderBase.filter()
Summary: StringIndexOutOfBoundsException WebAppClassLoaderBase.filter()
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 8.0.32
Hardware: All All
: P2 major with 1 vote (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 59013 59110 59282 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-02-11 21:05 UTC by Shon Vella
Modified: 2016-04-06 18:40 UTC (History)
4 users (show)



Attachments
patch (6.08 KB, patch)
2016-02-12 08:25 UTC, Violeta Georgieva
Details | Diff
Test case to reproduce the bug when using a script engine in a servlet (4.03 KB, application/octet-stream)
2016-02-15 16:01 UTC, Sebastian Staack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shon Vella 2016-02-11 21:05:03 UTC
This appears to be caused by the recent change listed in the changelog as:

"Fix class loader decision on the delegation for class loading and resource lookup and make it faster too. (rjung)"

org.apache.catalina.loader.WebAppClassLoaderBase.filter() is testing if name starts with "javax" or "org", and then tries to get the next character using name.charAt(). But if name is just "javax" or "org", then name.charAt() for the next character will throw StringIndexOutOfBoundsException.

the following jsp demonstrates the issue:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
    <title>$Title$</title>
</head>
<body>
<%
    Class.forName("org");
%>
</body>
</html>

Which results in rather than the expected ClassNotFoundException, causes instead:

java.lang.StringIndexOutOfBoundsException: String index out of range: 3
	java.lang.String.charAt(String.java:658)
	org.apache.catalina.loader.WebappClassLoaderBase.filter(WebappClassLoaderBase.java:2780)
	org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1253)
	org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1142)
	org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:125)
	org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:62)
	java.lang.Class.forName0(Native Method)
	java.lang.Class.forName(Class.java:264)
	org.apache.jsp.index_jsp._jspService(index_jsp.java:116)
	org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:438)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
	org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

While this example is contrived, it causes real world problems for Mozilla Rhino which is testing "java", "javax", "org", "com", "edu", "net", to make sure that they are indeed top-level packages and do not resolve to a class and can deal with the expected ClassNotFoundException but can't deal with the unexpected StringIndexOutOfBoundsException.
Comment 1 Violeta Georgieva 2016-02-12 08:25:17 UTC
Created attachment 33549 [details]
patch

Hi,

I'm attaching here a patch proposal so that others can comment.

I found one more problem:

Packages 
org.apache.tomcat.jdbc 
javax.servlet.jsp.jstl 

should be permitted, but the current implementation allows only sub packages for these packages.

Regards,
Violeta
Comment 2 Shon Vella 2016-02-12 15:34:09 UTC
Looked over the patch and I think the changes for org.apache.tomcat.jdbc 
javax.servlet.jsp.jstl will now incorrectly detect things like org.apache.tomcat.jdbcx and javax.servlet.jsp.jstly - Not very likely to happen in the wild I know, but I wouldn't have thought org and javax would have been very likely either.
Comment 3 Violeta Georgieva 2016-02-12 16:49:45 UTC
(In reply to Shon Vella from comment #2)
> Looked over the patch and I think the changes for org.apache.tomcat.jdbc 
> javax.servlet.jsp.jstl will now incorrectly detect things like
> org.apache.tomcat.jdbcx and javax.servlet.jsp.jstly - Not very likely to
> happen in the wild I know, but I wouldn't have thought org and javax would
> have been very likely either.

If you read again the code you will see that the check for these packages (org.apache.tomcat.jdbc, javax.servlet.jsp.jstl) is introduced in order to permit them not to deny them.
So if there are packages in the client code that are like those that you described above then they will be permitted.

Regards,
Violeta
Comment 4 Rainer Jung 2016-02-12 20:48:20 UTC
Thanks to the OP for analysing the problem and to Violeta for the patch.

Please have a look at r1730101, which fixes the StringIndexOutOfBoundsException.

The onyl problem I saw was the charAt(), because indeed the index could have been to big. For the startsWith(), this can not happen, because the given index is always equals to the known minimal length of the string (one more than the last index of the string). Javadoc tells us this is allowed, even an index bigger than the string length is allowed here: "The result is false if toffset is negative or greater than the length of this String object".

Concerning the filtering, when the name parameter is exactly equals to one of the denied package names (package names to filter), IMHO it is OK to permit them unless they are followed by a sub package, class or resource name. I see no harm in permitting the package names without anything after them.

If you agree, I'll backport.
Comment 5 Violeta Georgieva 2016-02-13 07:51:12 UTC
(In reply to Rainer Jung from comment #4)
> Thanks to the OP for analysing the problem and to Violeta for the patch.
> 
> Please have a look at r1730101, which fixes the
> StringIndexOutOfBoundsException.
> 
> The onyl problem I saw was the charAt(), because indeed the index could have
> been to big. For the startsWith(), this can not happen, because the given
> index is always equals to the known minimal length of the string (one more
> than the last index of the string). Javadoc tells us this is allowed, even
> an index bigger than the string length is allowed here: "The result is false
> if toffset is negative or greater than the length of this String object".
> 
> Concerning the filtering, when the name parameter is exactly equals to one
> of the denied package names (package names to filter), IMHO it is OK to
> permit them unless they are followed by a sub package, class or resource
> name. I see no harm in permitting the package names without anything after
> them.
> 
> If you agree, I'll backport.

Thanks,
Violeta
Comment 6 Rainer Jung 2016-02-13 11:00:51 UTC
Backported to TC 8 in r1730178.
Comment 7 Rainer Jung 2016-02-13 11:02:02 UTC
The fix will be part of the next releases 9.0.0.M4 and 8.0.33.
Comment 8 Sebastian Staack 2016-02-15 15:59:56 UTC
I got the same exception if I use a script engine in a servlet. I created a test case and attached it to the ticket. If you would like to check if this corner case is also fixed run "mvn clean verify" in the folder contained in the attached zip.
Comment 9 Sebastian Staack 2016-02-15 16:01:51 UTC
Created attachment 33559 [details]
Test case to reproduce the bug when using a script engine in a servlet
Comment 10 Rainer Jung 2016-02-15 19:25:08 UTC
Your test case shows the same problem, trying to load a class named "org". I added logging to the filter method to track what calls it gets.

I replaced the catalina.jar from 8.0.32 with one from the current tc8.0.x HEAD, and the test case then succeeds. So the fix we have already applied for the next release also fixes your test.

You can apply the following patch/fix on top of TC 8.0.32 if you like.

Regards,

Rainer
Comment 12 Violeta Georgieva 2016-02-16 16:13:47 UTC
*** Bug 59013 has been marked as a duplicate of this bug. ***
Comment 13 Violeta Georgieva 2016-03-03 15:08:14 UTC
*** Bug 59110 has been marked as a duplicate of this bug. ***
Comment 14 Violeta Georgieva 2016-04-06 18:40:03 UTC
*** Bug 59282 has been marked as a duplicate of this bug. ***