StringIndexOutOfBoundsException - Tomcat8.0.32

Bug #1606331 reported by Samuel Longiaru on 2016-07-25
54
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Tomcat7
Fix Released
High
tomcat8 (Ubuntu)
Undecided
Unassigned
Xenial
High
Nish Aravamudan
Yakkety
Undecided
Unassigned

Bug Description

[Impact]

 * There was a software bug in the 8.0.32 release of tomcat8, subsequently fixed in 8.0.33, with acessing past the end of a string.

[Test Case]

 * The Apache bug provides a test case.

[Regression Potential]

* This is a strict backport from upstream of a bugfix. The regression potential is very low, as the current tomcat8 code is broken.

---

Tomcat 8.0.32 has a known and corrected bug

https://bz.apache.org/bugzilla/show_bug.cgi?id=58999

which in some cases prevents a webapp from executing. I have encountered this error. The fix will be to place a later version of Tomcat8 into the Ubuntu 16.04 repository.

I encountered this error using:

----------------------------

OpenVPMS 1.8.1 (veterinary practice management webapp)
MySQL 5.7.13
Open-jdk 1.8.0_91
Tomcat 8.0.32
mysql-connector-java-5.1.39

----------------------------

The webapp in this case (OpenVPMS) runs under tomcat7 but not under this specific version of Tomcat (8.0.32). Instead, tomcat throws a 404-/openvpms error. The relevant portion of the tomcat log is:

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 3
 at java.lang.String.charAt(String.java:658)
 at org.apache.catalina.loader.WebappClassLoaderBase.filter(WebappClassLoaderBase.java:2780)
 at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1253)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:348)

Thank you.

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.

Created attachment 33549
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

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.

(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

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.

(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

Backported to TC 8 in r1730178.

The fix will be part of the next releases 9.0.0.M4 and 8.0.33.

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.

Created attachment 33559
Test case to reproduce the bug when using a script engine in a servlet

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

*** Bug 59013 has been marked as a duplicate of this bug. ***

*** Bug 59110 has been marked as a duplicate of this bug. ***

*** Bug 59282 has been marked as a duplicate of this bug. ***

affects: ubuntu → tomcat8 (Ubuntu)
tags: added: xenial
removed: tomcat8
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in tomcat8 (Ubuntu):
status: New → Confirmed
Changed in tomcat8 (Ubuntu):
importance: Undecided → Critical
Changed in tomcat7:
importance: Unknown → High
status: Unknown → Fix Released
Hendrik Brummermann (nhnb) wrote :

Is there any hope to get this fix of Tomcat 8.0.32 into Ubuntu 16.04?

This issue affects all Tomcat based web-applications that make use of server side JavaScript, such as the German university management system HISinOne.

Robie Basak (racb) wrote :

I don't think this qualifies as Critical under the definition at https://wiki.ubuntu.com/Bugs/Importance.

Changed in tomcat8 (Ubuntu):
importance: Critical → High
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

If someone can prepare a backport, please follow the steps at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to have 16.04 updated.

All the steps documented there need to be followed. In particular, I'm concerned that we:

1) Explain the bug well enough so the SRU team (who are probably not familiar with this package) can understand the real user impact in terms of use case so they can make a decision as to whether backporting the fix to stable releases justifies the regression risk to existing, unaffected users.

2) Make sure that the fixing this in a stable Ubuntu release does not regress existing users of the module not affected by this bug.

3) Have a test case that can be followed by someone not familiar with the package for SRU verification purposes.

Nish Aravamudan (nacc) wrote :

Zesty and Yakkety both have > 8.0.33 where the bug is fixed. Only Xenial needs the backport now.

Changed in tomcat8 (Ubuntu):
status: Confirmed → Fix Released
Changed in tomcat8 (Ubuntu Xenial):
status: New → Triaged
importance: Undecided → High
Changed in tomcat8 (Ubuntu):
importance: High → Undecided
Changed in tomcat8 (Ubuntu Xenial):
assignee: nobody → Nish Aravamudan (nacc)
status: Triaged → In Progress
Nish Aravamudan (nacc) on 2016-12-09
Changed in tomcat8 (Ubuntu Yakkety):
status: New → Fix Released
Nish Aravamudan (nacc) wrote :

Please test tomcat8 https://launchpad.net/~nacc/+archive/ubuntu/tomcat8v2 8.0.32-1ubuntu1.3~ppa1.

Nish Aravamudan (nacc) on 2016-12-14
description: updated
description: updated
Samuel Longiaru (longiaru) wrote :

After adding ppa and updating, OpenVPMS webapp now runs as expected. Thanks!

Conrad Kostecki (conikost) wrote :

I also confirm. Using tomcat8 from ppa works and solves our problem.

Nish Aravamudan (nacc) wrote :

Thank you to Samuel and Conrad! Can you, as a favor to me, test the (now-building) tomcat8 - 8.0.32-1ubuntu1.3~ppa2 from the same PPA to verify no regression in your use-cases? It includes an additional bugfix from 8.0.33 for LP: #1593854.

Samuel Longiaru (longiaru) wrote :

Nish,

I have just tried the ~ppa2 version with good success. I had trouble forcing the upgrade to ~ppa2 so wound up purging tomcat8 and reinstalling. I have confirmed the use of ~ppa2 with apt-show-versions | grep 'tomcat8'. All are showing ~ppa2.

Thank you for your help!

Jeremy (nzlamb) wrote :

This patch also fixed a minor rendering issue with Xwiki (refer http://jira.xwiki.org/browse/XWIKI-13970).

Can we please have it released to the main repositories soon?

Conrad Kostecki (conikost) wrote :

Any news on getting this into the main repositories?

Samuel Longiaru (longiaru) wrote :

Too bad that the tested patch for this high importance bug did not make it into the Jan 23, 2017 Tomcat8 update for 14.04 LTS. Any idea when the next one is coming out that may include this bug fix?

sw (sw-ubuntu) wrote :

Any update on a fix for Xenial? This issue prevents some functionality (e.g. the code macro) on my xwiki installation. Unfortunately xwiki isn't running properly after an upgrade to Bionic Beaver so I'm stuck with this problem currently.

Alternatively - Is there any way to upgrade tomcat8 via ppa to a current tomcat8 version with the fix? Currently I run the latest Version 8.0.32-1ubuntu1.7 and I don't find a way to resolve it. (Manual install is no option -> security fixes etc.)

Robie Basak (racb) on 2018-08-17
tags: added: bitesize
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.