On 18/03/17 20:04, Olaf Kock wrote: > Am 18.03.2017 um 10:54 schrieb Mark Thomas: >> On 17/03/2017 20:21, Mike Wilson wrote: >>> I also ran into [1]. >>> >>> Some Tomcat configuration with custom components (Valves, Managers etc) may >>> be done from a webapp's META-INF/context.xml. But currently if those classes >>> are your own custom implementations they will not be found if residing >>> inside the webapp's war (but are f ex found if placed in <tomcat>/lib). >>> >>> Would it make sense for Tomcat to use the webapp classloader for components >>> that are specified in META-INF/context.xml? >> Potentially. It needs some thought when running under a SecurityManager. > Mark, > you probably know better than me - is there any kind of security > assumption involved when referencing connection pools etc? The nice > thing about JNDI resources (etc) is that the application has no > knowledge of database credentials (unless tricking with reflection) - > but if it can inject its own classes this way, I'd not be sure any more.
Hmm. I'd need to do some investigation to see what is possible. Generally, I'd assume a web application has read access to the JNDI config. If I am right, I'm not sure how practical it would be to stop that. > Sure, this would be a server side attack, of a rogue web application. > Not sure if this thought is valid or not - I just wanted to raise the > issue so that it can be defeated or taken into account. Maybe this is > what you meant with "when running under a SecurityManager". This scenario is pretty rare. The most regularly cited use case is shared hosting with multiple untrusted users sharing a single Tomcat instance. Given how trivial it is for one app to DoS the entire server (code a JSP with a tight loop, request that JSP once per server code, server locks up) this isn't a deployment strategy that gets used much. One app, one Tomcat instance is a lot easier to manage in all sorts of ways. We do try and protect against rouge apps running under a security manager. Generally, bypassing the security manager gets treated as a low severity (because it affects so few people) vulnerability. For example, we recently blocked apps accessing global resources unless they were explicitly linked to that resource (CVE-2016-6797). Because custom Valves, Managers, etc. have access to Tomcat's internals and do get called in the container's security context we'd need to be careful. They all require configuration via context.xml and that gets special treatment when running under a security manager. It requires the system admin to explicitly copy the app provided context.xml to $CATALINA_BASE/<engine>/<host> to enable it. The idea is that the admin reviews the contents and only does this if it is safe. Working out what is safe is rather tricky though. That would get even harder in the case of a custom Manager etc. In short it is a lot easier to treat the entire Tomcat instance as untrusted rather than the container as trusted but not the app (or one of the apps running on it). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
