Bug#845425: DataSource no longer accessible since jessie security update

[Emmanuel Bourg]

Le 7/12/2016 à 20:16, Arne Nordmark a écrit :

> OK. I first built 7.0.56-3+deb8u5 as distributed, installed, and
> verified that your example works but not my webapp. Then I added the
> loop to validateGlobalResourceAccess() (patch attached), reinstalled
> libtomcat7-java, restarted tomcat7, and verified that both webapps now work.
> 
> Thanks for your patience,

Thanks a lot for the tests Arne. We are basically missing the commit
1763236 [1]  that added the recursion through the classloader hierarchy.
This commit wasn't documented as related to CVE-2016-6797. I'll add it
in the next update. The tomcat8 package is also affected.

Emmanuel Bourg

[1] https://svn.apache.org/r1763236

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-12-07 kl. 17:35, skrev Emmanuel Bourg:
> Le 7/12/2016 à 13:28, Arne Nordmark a écrit :
> 
> Thanks for the info. I'm trying to reproduce the same error but I
> haven't succeeded so far. Here is was I did:
> 

...

> 9. Create a test page /var/lib/tomcat7/webapps/ROOT/test.jsp with:
> 
>   <%@page import="javax.naming.*,javax.sql.*" %>
>   <%
>   Context initContext = new InitialContext();
>   Context envContext  = (Context) initContext.lookup("java:/comp/env");
>   DataSource ds = (DataSource) envContext.lookup("jdbc/test");
> 
>   out.println("DataSource: " + ds);
>   %>
> 
> There is still something different with your setup but I don't know what.

If I add

  out.println("Loaded by: " + ds.getClass().getClassLoader());

to test.jsp I get

Loaded by: org.apache.catalina.loader.StandardClassLoader@4876e0

so the WebappClassLoader is not being used in this example, probably
because there are no classes in the webapp.

> 
> 
>> Am I correct in understanding that you want me to add the loop on top of
>> version 7.0.56-3+deb8u5 without the other changes from upstream 7.0.73?
> 
> Yes please.

OK. I first built 7.0.56-3+deb8u5 as disatributed, installed, and
verified that your example works but not my webapp. Then I added the
loop to validateGlobalResourceAccess() (patch attached), reinstalled
libtomcat7-java, restarted tomcat7, and verified that both webapps now work.

> 
> Emmanuel Bourg
> 

Thanks for your patience,
Arne
--- a/java/org/apache/naming/factory/ResourceLinkFactory.java
+++ b/java/org/apache/naming/factory/ResourceLinkFactory.java
@@ -116,9 +116,12 @@
 
 private static boolean validateGlobalResourceAccess(String globalName) {
 ClassLoader cl = Thread.currentThread().getContextClassLoader();
-Map registrations = globalResourceRegistrations.get(cl);
-if (registrations != null && registrations.containsValue(globalName)) {
-return true;
+while (cl != null) {
+Map registrations = globalResourceRegistrations.get(cl);
+if (registrations != null && registrations.containsValue(globalName)) {
+return true;
+}
+cl = cl.getParent();
 }
 return false;
 }
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Emmanuel Bourg]

Le 7/12/2016 à 13:28, Arne Nordmark a écrit :

> I have put a symlink in /var/lib/tomcat7/common, so that would be loaded
> by the "Common" class loader.
> 
> The default Debian configuration in /etc/tomcat7/catalina.properties
> seem to be slightly broken here, so in the "common.loader" I had to
> change from ${catalina.home}/common/... to ${catalina.base}/common/...

Thanks for the info. I'm trying to reproduce the same error but I
haven't succeeded so far. Here is was I did:

1. Install tomcat7 on Jessie (version 7.0.56-3+deb8u5)

2. Create the /var/lib/tomca7/common directory

3. Modify common.loader in /etc/tomcat7/catalina.properties
   to include ${catalina.base}/common/*.jar (this will be fixed
   in the next version of tomcat8 btw)

4. Install libmysql-java

5. Create a symlink to mysql-connector-java.jar
   in /var/lib/tomcat7/common

6. Declare a datasource in /etc/tomcat7/server.xml:

  

7. Create context.xml in /var/lib/tomcat7/webapps/ROOT/META-INF/

8. Link the datasource in context.xml:

  

  

9. Create a test page /var/lib/tomcat7/webapps/ROOT/test.jsp with:

  <%@page import="javax.naming.*,javax.sql.*" %>
  <%
  Context initContext = new InitialContext();
  Context envContext  = (Context) initContext.lookup("java:/comp/env");
  DataSource ds = (DataSource) envContext.lookup("jdbc/test");

  out.println("DataSource: " + ds);
  %>

10. Open http://localhost:8080/test.jsp

There is still something different with your setup but I don't know what.


> Am I correct in understanding that you want me to add the loop on top of
> version 7.0.56-3+deb8u5 without the other changes from upstream 7.0.73?

Yes please.

Emmanuel Bourg

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-12-07 kl. 11:38, skrev Emmanuel Bourg:

Hi Arne,

Were is located the jar of your JDBC driver?


I have put a symlink in /var/lib/tomcat7/common, so that would be loaded 
by the "Common" class loader.


The default Debian configuration in /etc/tomcat7/catalina.properties 
seem to be slightly broken here, so in the "common.loader" I had to 
change from ${catalina.home}/common/... to ${catalina.base}/common/...





I can build and run Debian tomcat7 on both wheezy and jessie, so if you
would like me to make any further tests, please let me know.


Would you be able to try again with the missing loop?


Am I correct in understanding that you want me to add the loop on top of 
version 7.0.56-3+deb8u5 without the other changes from upstream 7.0.73?




Emmanuel Bourg



Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Emmanuel Bourg]

Hi Arne,

Were is located the jar of your JDBC driver?

> I can build and run Debian tomcat7 on both wheezy and jessie, so if you
> would like me to make any further tests, please let me know.

Would you be able to try again with the missing loop?

Emmanuel Bourg

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Markus Koschany]

On 04.12.2016 15:39, Arne Nordmark wrote:
> Den 2016-12-04 kl. 15:00, skrev Markus Koschany:
>> On 04.12.2016 09:22, Arne Nordmark wrote:
>>> Unfortunately, the newly released wheezy security update 7.0.28-4+deb7u7
>>> also suffers from this problem.
>>>
>>> Can it be so that the important part missing is the loop traversing the
>>> class loaders in validateGlobalResourceAccess():
>>>
>>> while (cl != null) {
>>>  ...
>>>  cl = cl.getParent();
>>> }
>>
>> Hello,
>>
>> I have prepared the update for Wheezy. Since you confirmed that using the 
>> ResourceLinkFactory class
>> from 7.x trunk works for you, we have replaced the current version with this 
>> one. At the moment I
>> fail to understand what we are missing because upstream's fix for 
>> CVE-2016-6797 is relatively
>> straightforward [1] and we have already taken your bug report into account.
>>
>> Could you elaborate in which file the code from above is missing?
> 
> Sorry if I was unclear. In the ResourceLinkFactory class,
> CVE-2016-6797.patch adds among other things the new method
> 
> private static boolean validateGlobalResourceAccess(String globalName)
> 
> However, the upstream version 7.0.73 there is another change to this new
> method, which is the loop over the parent class loaders I was referring
> to above.
> 
> It seems that when preparing CVE-2016-6797-part2.patch, this change was
> left out, but it may be the change that actually makes things work.
> 
> I can build and run Debian tomcat7 on both wheezy and jessie, so if you
> would like me to make any further tests, please let me know.

My bad. It seems I have copied ResourceLinkFactory from another branch which is 
not equivalent to
7.0.73.

https://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/naming/factory/?pathrev=1757275

Looking at Apache's github repository for Tomcat 7, the loop is indeed present.

https://raw.githubusercontent.com/apache/tomcat70/TOMCAT_7_0_73/java/org/apache/naming/factory/ResourceLinkFactory.java

I will use this version when I prepare a regression update. Since you have 
already confirmed that
this fixes #845425 further tests won't be necessary. Thanks for your help!







signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-12-04 kl. 15:00, skrev Markus Koschany:
> On 04.12.2016 09:22, Arne Nordmark wrote:
>> Unfortunately, the newly released wheezy security update 7.0.28-4+deb7u7
>> also suffers from this problem.
>>
>> Can it be so that the important part missing is the loop traversing the
>> class loaders in validateGlobalResourceAccess():
>>
>> while (cl != null) {
>>  ...
>>  cl = cl.getParent();
>> }
> 
> Hello,
> 
> I have prepared the update for Wheezy. Since you confirmed that using the 
> ResourceLinkFactory class
> from 7.x trunk works for you, we have replaced the current version with this 
> one. At the moment I
> fail to understand what we are missing because upstream's fix for 
> CVE-2016-6797 is relatively
> straightforward [1] and we have already taken your bug report into account.
> 
> Could you elaborate in which file the code from above is missing?

Sorry if I was unclear. In the ResourceLinkFactory class,
CVE-2016-6797.patch adds among other things the new method

private static boolean validateGlobalResourceAccess(String globalName)

However, the upstream version 7.0.73 there is another change to this new
method, which is the loop over the parent class loaders I was referring
to above.

It seems that when preparing CVE-2016-6797-part2.patch, this change was
left out, but it may be the change that actually makes things work.

I can build and run Debian tomcat7 on both wheezy and jessie, so if you
would like me to make any further tests, please let me know.

Thanks,
Arne

> 
> Thanks,
> 
> Markus
> 
> 
> [1] https://svn.apache.org/viewvc?view=revision=1757275
> 
> 
> 
> 
> 

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Markus Koschany]

On 04.12.2016 09:22, Arne Nordmark wrote:
> Unfortunately, the newly released wheezy security update 7.0.28-4+deb7u7
> also suffers from this problem.
> 
> Can it be so that the important part missing is the loop traversing the
> class loaders in validateGlobalResourceAccess():
> 
> while (cl != null) {
>  ...
>  cl = cl.getParent();
> }

Hello,

I have prepared the update for Wheezy. Since you confirmed that using the 
ResourceLinkFactory class
from 7.x trunk works for you, we have replaced the current version with this 
one. At the moment I
fail to understand what we are missing because upstream's fix for CVE-2016-6797 
is relatively
straightforward [1] and we have already taken your bug report into account.

Could you elaborate in which file the code from above is missing?

Thanks,

Markus


[1] https://svn.apache.org/viewvc?view=revision=1757275







signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Unfortunately, the newly released wheezy security update 7.0.28-4+deb7u7
also suffers from this problem.

Can it be so that the important part missing is the loop traversing the
class loaders in validateGlobalResourceAccess():

while (cl != null) {
 ...
 cl = cl.getParent();
}

Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-11-23 kl. 17:52, skrev Emmanuel Bourg:
> Would you be able to rebuild with this version of the
> ResourceLinkFactory class and see if it works better?
> 
> https://raw.githubusercontent.com/apache/tomcat70/TOMCAT_7_0_73/java/org/apache/naming/factory/ResourceLinkFactory.java
> 

Indeed, with this file, things seem to work (crossing my fingers that I
have understood how to use quilt, and thus built correctly). I had to
make one change to line 43 to make it compile.

I am attaching the refreshed version of CVE-2016-6797.patch for reference.

Merci beaucoup,
Arne


Description: Fixes CVE-2016-6797: The ResourceLinkFactory did not limit web
 application access to global JNDI resources to those resources explicitly
 linked to the web application. Therefore, it was possible for a web
 application to access any global JNDI resource whether an explicit
 ResourceLink had been configured or not.
Origin: backport, https://svn.apache.org/r1757275
--- a/java/org/apache/catalina/core/NamingContextListener.java
+++ b/java/org/apache/catalina/core/NamingContextListener.java
@@ -41,6 +41,7 @@
 import org.apache.catalina.ContainerEvent;
 import org.apache.catalina.ContainerListener;
 import org.apache.catalina.Context;
+import org.apache.catalina.Engine;
 import org.apache.catalina.Host;
 import org.apache.catalina.Lifecycle;
 import org.apache.catalina.LifecycleEvent;
@@ -68,6 +69,7 @@
 import org.apache.naming.ResourceRef;
 import org.apache.naming.ServiceRef;
 import org.apache.naming.TransactionRef;
+import org.apache.naming.factory.ResourceLinkFactory;
 import org.apache.tomcat.util.modeler.Registry;
 import org.apache.tomcat.util.res.StringManager;
 
@@ -344,6 +346,11 @@
 registry.unregisterComponent(objectName);
 }
 }
+
+javax.naming.Context global = getGlobalNamingContext();
+if (global != null) {
+ResourceLinkFactory.deregisterGlobalResourceAccess(global);
+}
 } finally {
 objectNames.clear();
 
@@ -1167,6 +1174,17 @@
 logger.error(sm.getString("naming.bindFailed", e));
 }
 
+ResourceLinkFactory.registerGlobalResourceAccess(
+getGlobalNamingContext(), resourceLink.getName(), resourceLink.getGlobal());
+}
+
+
+private javax.naming.Context getGlobalNamingContext() {
+if (container instanceof Context) {
+Engine e = (Engine) ((Context) container).getParent().getParent();
+return e.getService().getServer().getGlobalNamingContext();
+}
+return null;
 }
 
 
@@ -1270,6 +1288,7 @@
 logger.error(sm.getString("naming.unbindFailed", e));
 }
 
+ResourceLinkFactory.deregisterGlobalResourceAccess(getGlobalNamingContext(), name);
 }
 
 
--- a/java/org/apache/naming/factory/ResourceLinkFactory.java
+++ b/java/org/apache/naming/factory/ResourceLinkFactory.java
@@ -5,20 +5,21 @@
  * The ASF licenses this file to You under the Apache License, Version 2.0
  * (the "License"); you may not use this file except in compliance with
  * the License.  You may obtain a copy of the License at
- * 
+ *
  *  http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
- */ 
-
-
+ */
 package org.apache.naming.factory;
 
+import java.util.HashMap;
 import java.util.Hashtable;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
 
 import javax.naming.Context;
 import javax.naming.Name;
@@ -28,35 +29,32 @@
 import javax.naming.spi.ObjectFactory;
 
 import org.apache.naming.ResourceLinkRef;
-
+import org.apache.naming.StringManager;
 
 /**
  * Object factory for resource links.
- * 
+ *
  * @author Remy Maucherat
  */
-public class ResourceLinkFactory
-implements ObjectFactory {
-
-
-// --- Constructors
-
+public class ResourceLinkFactory implements ObjectFactory {
 
 // --- Static Variables
 
+private static final StringManager sm = StringManager.getManager(Constants.Package);
 
 /**
  * Global naming context.
  */
 private static Context globalContext = null;
 
+private static Map> globalResourceRegistrations =
+new ConcurrentHashMap>();
 
 // - Public Methods
 
-
 /**
  * Set the global context (note: can only be used once).
- * 
+ *
  * @param newGlobalContext new global context value
  */
 public static void 

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-11-23 kl. 17:52, skrev Emmanuel Bourg:
> 
> Would you be able to rebuild with this version of the
> ResourceLinkFactory class and see if it works better?
> 
> https://raw.githubusercontent.com/apache/tomcat70/TOMCAT_7_0_73/java/org/apache/naming/factory/ResourceLinkFactory.java
> 

I take it you mean this in addition to the other changes in
CVE-2016-6797.patch?

Will do.

Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Emmanuel Bourg]

Le 23/11/2016 à 17:06, Arne Nordmark a écrit :
> Yet another data point:
> 
> I rebuilt 7.0.56-3+deb8u5 with CVE-2016-6797.patch deleted, and again
> the problem goes away.

Would you be able to rebuild with this version of the
ResourceLinkFactory class and see if it works better?

https://raw.githubusercontent.com/apache/tomcat70/TOMCAT_7_0_73/java/org/apache/naming/factory/ResourceLinkFactory.java

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Yet another data point:

I rebuilt 7.0.56-3+deb8u5 with CVE-2016-6797.patch deleted, and again
the problem goes away.

Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-11-23 kl. 14:09, skrev Emmanuel Bourg:
> Did you enable the security manager?

I have not changed that part of /etc/default/tomcat7, so it still reads

#TOMCAT7_SECURITY=no

which should imply that the security manager is not enabled.

Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Emmanuel Bourg]

Le 23/11/2016 à 12:54, Arne Nordmark a écrit :

> Thanks for the quick reply.
> 
> No, with version 7.0.73-1~bpo8+1 I do not have this problem. I guess
> this indicates a problem with backporting the patch to 7.0.56.

Did you enable the security manager?

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Den 2016-11-23 kl. 12:36, skrev Emmanuel Bourg:
> Hi Arne,
> 
> Thank you for reporting this issue. Could you check if it also occurs
> with the tomcat7 package from jessie-backports please?

Thanks for the quick reply.

No, with version 7.0.73-1~bpo8+1 I do not have this problem. I guess
this indicates a problem with backporting the patch to 7.0.56.

> 
> Emmanuel Bourg
> 

Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Emmanuel Bourg]

Hi Arne,

Thank you for reporting this issue. Could you check if it also occurs
with the tomcat7 package from jessie-backports please?

Emmanuel Bourg

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#845425: DataSource no longer accessible since jessie security update

[Arne Nordmark]

Package: tomcat7
Version: 7.0.56-3+deb8u5
Severity: normal

After the security update 7.0.56-3+deb8u5, I get an error message:

ALLVARLIG: Servlet.service() for servlet [Faces Servlet] in context with
path [/mech] threw exception [Filter execution threw an exception] with
root cause
org.hibernate.HibernateException: Unable to determine appropriate
DataSource to use

This seems likely to be connected with the fix for bug #842666, but I am
not expert enough to determine whether this is due to misconfiguration,
a problem with the fix, a problem in Hibernate, or ...

It used to work with 7.0.56-3+deb8u4, and downgrading to 7.0.56-3+deb8u3
from stable also restores the functionality.

/etc/tomcat7/server.xml:
...
  
...
   
   
...
  
...

webapp/META-INF/context.xml:

  


Thanks,
Arne

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.