Re: apps conversion from 3.3.1 to 4.1.12
On Thu, 10 Oct 2002, Henri Gomez wrote: Date: Thu, 10 Oct 2002 08:10:03 +0200 From: Henri Gomez [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: apps conversion from 3.3.1 to 4.1.12 If this reference is in your web.xml file, then my suggestion is already being done. To test it, try temporarily copying the settings.xml file into the WEB-INF directory and changing the relative URL appropriately. Putting the file in WEB-INF works, even if I use ../settings, ie directly in webapps/ROOT. I'd be -1 on removing the security check in 4.x/5.x. Fixing 3.3.2 sounds like a good idea. I'll be -1 to fix the 3.3.2 for many reasons : - It will brake all deployment strategy - I'm still not sure it's a security problem since nobody prevent you to change to PUBLIC and goes outside : !ENTITY % settings SYSTEM ../../../settings.xml %settings; to !ENTITY % settings PUBLIC hackme http://hackme.com/settings.xml; %settings; That's more than insecure isn't it ? Not if you put the settings file inside /WEB-INF where it is not accessible to external clients. I take a look in specs and didn't see anything preventing you to have entities located outside WEBAPP so I feel it's a regression and not a security feature. Ad minima, in TC 4.x and 5.x, there should be a setting in web.xml, or server.xml to enable this behaviour even if it's prevented by default. -1, for at least three reasons: * Such a path is non-sensical when you run webapps directly from WAR files, because the base resource (inside the WAR) does not have a file path. * The URL to the base resource is being handled by a URLStreamHandler provided by the servlet container (the jndi: prefix in Tomcat 4), and the spec disallows access to resources outside the WAR. * The behavior you describe would allow any webapp to snoop the entire directory structure of your server with a suitably construced relative path. *You* may be running on an OS that supports access permissions (and understand how to use them), but that doesn't help the poor sod who uses something like Win98. Keep in mind that if it works here, it will also would work on something like: InputStream stream = getServletContext().getResourceAsStream(../../../etc/passwd); with some suitable number of .. depending on where you've got Tomcat installed. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Craig R. McClanahan wrote: Keep in mind that if it works here, it will also would work on something like: InputStream stream = getServletContext().getResourceAsStream(../../../etc/passwd); with some suitable number of .. depending on where you've got Tomcat installed. And of course, someone could just write InputStream stream=new FileInputStrea(/etc/passwd) and not bother with any ... Same for any other processing done with jdni: URL paths or not. I agree however that people shouldn't rely on resources outside a webapplication + relative paths - that's just bad programming in this environment. But it has nothing to do with security - the only way to protect against access to resources is to use a sandbox. If you don't - _anything_ is possible for the user ( including System.execute(rm -rf /)). Any restrictions on the grounds that it 'increase security' are wrong and just give a false sense of security ( which is pretty dangerous in itself). I am -1 on fixing this on 3.3 - but +1 on adding some documentation/readme that using this feature is not portable and will not work on other containers. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: apps conversion from 3.3.1 to 4.1.12
From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Costin Manolache Sent: Thursday, October 10, 2002 10:26 PM against access to resources is to use a sandbox. If you don't - ok, i understand, thanks.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Henri Gomez wrote: Hi to all, While converting some applications from 3.3.1 to 4.1.12 I noticed some little problems. 1) We used to define our own default servlet, but 4.1.x definie its own default in conf/web.xml. Could we change from org.apache.catalina.servlets.DefaultServlet to our actual default servlet, knowing that all webapps use the same code base ? In that case should the jar containing the default servlet could be in common/lib ? AFAIK, yes. You should be able to put it in shared/lib. The webapp settings also override the global settings. 2) We also used to include external entities in web.xml which live outside webapp dir : ie : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % settings SYSTEM ../../../settings.xml %settings; ] ... Digester find settings.xml only when it's located in WEB-INF or webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml). How could I make it find the settings.xml outside webapps area ? via conf/catalina.policy ? This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Remy Maucherat wrote: Henri Gomez wrote: Hi to all, While converting some applications from 3.3.1 to 4.1.12 I noticed some little problems. 1) We used to define our own default servlet, but 4.1.x definie its own default in conf/web.xml. Could we change from org.apache.catalina.servlets.DefaultServlet to our actual default servlet, knowing that all webapps use the same code base ? In that case should the jar containing the default servlet could be in common/lib ? AFAIK, yes. You should be able to put it in shared/lib. The webapp settings also override the global settings. Great. 2) We also used to include external entities in web.xml which live outside webapp dir : ie : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % settings SYSTEM ../../../settings.xml %settings; ] ... Digester find settings.xml only when it's located in WEB-INF or webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml). How could I make it find the settings.xml outside webapps area ? via conf/catalina.policy ? This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. I'll check for it, thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 08, 2002 11:33 PM Subject: apps conversion from 3.3.1 to 4.1.12 Hi to all, While converting some applications from 3.3.1 to 4.1.12 I noticed some little problems. Wot? 3.3.1 isn't good enough for you any more. ;-) 1) We used to define our own default servlet, but 4.1.x definie its own default in conf/web.xml. Could we change from org.apache.catalina.servlets.DefaultServlet to our actual default servlet, knowing that all webapps use the same code base ? In that case should the jar containing the default servlet could be in common/lib ? Without testing, in theory you can put your jar in common/lib, and change the classname for default in conf/web.xml and the only bugs will be yours. :) Note, that this is more than you can do with 3.3.1. 2) We also used to include external entities in web.xml which live outside webapp dir : ie : ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2.2.dtd; [ !ENTITY % settings SYSTEM ../../../settings.xml %settings; ] ... Digester find settings.xml only when it's located in WEB-INF or webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml). How could I make it find the settings.xml outside webapps area ? via conf/catalina.policy ? This has always been a headache for me on all Tomcat versions. However, I don't think that internal-entities can be used at all (usefully). Thanks for you help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Digester code is derived from XmlMapper which is able to locate entities in ../../../ directories. My concern here is : Specs didn't mentions restriction on use of external entities outside the webapp. So it should be granted by default isn't it ? I take a look at FileDirContext but I didn't understand what allowLinking is ? So my question is : bug or feature ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Remy Maucherat wrote: Henri Gomez wrote: This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Digester code is derived from XmlMapper which is able to locate entities in ../../../ directories. My concern here is : Specs didn't mentions restriction on use of external entities outside the webapp. So it should be granted by default isn't it ? I take a look at FileDirContext but I didn't understand what allowLinking is ? So my question is : bug or feature ? There's a pretty strict check on the canonical path of a resource which I added. I consider it a security feature. I think a webapp should be self contained, so I think it's reasonable to have the check as the default. allowLinking disables the check. Don't be lazy, just do a search in FileDirContext ;-) I take a look at this but but digester didn't use FileDirContext so the allowLinking didn't fit. The problem seems be only in Digester which fail to load ../../../settings.xml What could we do ? PS: I tried with TC 4.1.x and all commons from CVS. at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344) at java.net.URL.openStream(URL.java:793) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:738) at org.apache.xerces.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:609) at org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(XMLDTDScannerImpl.java:1927) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(XMLDTDScannerImpl.java:1889) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(XMLDTDScannerImpl.java:359) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:808) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1542) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.java:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
On Wed, 9 Oct 2002, Henri Gomez wrote: Date: Wed, 09 Oct 2002 17:39:00 +0200 From: Henri Gomez [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: apps conversion from 3.3.1 to 4.1.12 Remy Maucherat wrote: Henri Gomez wrote: This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Digester code is derived from XmlMapper which is able to locate entities in ../../../ directories. My concern here is : Specs didn't mentions restriction on use of external entities outside the webapp. So it should be granted by default isn't it ? I take a look at FileDirContext but I didn't understand what allowLinking is ? So my question is : bug or feature ? There's a pretty strict check on the canonical path of a resource which I added. I consider it a security feature. I think a webapp should be self contained, so I think it's reasonable to have the check as the default. allowLinking disables the check. Don't be lazy, just do a search in FileDirContext ;-) I take a look at this but but digester didn't use FileDirContext so the allowLinking didn't fit. The problem seems be only in Digester which fail to load ../../../settings.xml What could we do ? Haven't looked at the code, but here's a couple of thoughts that might help: If your path above (../../../settings.xml) is attempting to go above the context root of the webapp, it's pretty much guaranteed to fail because of the security restrictions. Undoing that restriction would just create a bunch of CERT reports about Tomcat letting you browse the entire directory structure of your disk. One of the important enablers for using external entity files in Digester is to use the Digester.parse() that takes an InputSource (rather than an InputStream), and be sure you have configured your InputSource to include the source URL. That is necessary for the XML parser to be able to resolve relative system ids. The code in ContextConfig that parses web.xml and TLD files was modified (a while back) to do this kind of thing, if you need an example. PS: I tried with TC 4.1.x and all commons from CVS. Craig at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344) at java.net.URL.openStream(URL.java:793) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:738) at org.apache.xerces.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:609) at org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(XMLDTDScannerImpl.java:1927) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(XMLDTDScannerImpl.java:1889) at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(XMLDTDScannerImpl.java:359) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:808) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1542) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.java:282) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Henri Gomez wrote: Remy Maucherat wrote: Henri Gomez wrote: This is likely the protection against reading anything outside the webapp root (see the allowLinking of FileDirContext), although I don't know how the digester will try to load the included file. Digester code is derived from XmlMapper which is able to locate entities in ../../../ directories. My concern here is : Specs didn't mentions restriction on use of external entities outside the webapp. So it should be granted by default isn't it ? I take a look at FileDirContext but I didn't understand what allowLinking is ? So my question is : bug or feature ? There's a pretty strict check on the canonical path of a resource which I added. I consider it a security feature. I think a webapp should be self contained, so I think it's reasonable to have the check as the default. allowLinking disables the check. Don't be lazy, just do a search in FileDirContext ;-) I take a look at this but but digester didn't use FileDirContext so the allowLinking didn't fit. The problem seems be only in Digester which fail to load ../../../settings.xml What could we do ? PS: I tried with TC 4.1.x and all commons from CVS. at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344) at java.net.URL.openStream(URL.java:793) Well, that's exactly the same. Where do you think that weird URL connection goes ?? (hint: to the aforementioned FileDirContext, through some classloader binding) The place where it gets rejected should be the FileDirContext.file() method, as far as I can remember. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344) at java.net.URL.openStream(URL.java:793) Well, that's exactly the same. Where do you think that weird URL connection goes ?? (hint: to the aforementioned FileDirContext, through some classloader binding) Well it's my initial diggs in TC 4.1.x, let me some time to discover it. The place where it gets rejected should be the FileDirContext.file() method, as far as I can remember. FileDirContext.file() is used to get webapps/ROOT/web.xml ref and validate access, but the external entity is grabbed from Digester so outside FileDirContext control (from my debug analyze). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
Haven't looked at the code, but here's a couple of thoughts that might help: If your path above (../../../settings.xml) is attempting to go above the context root of the webapp, it's pretty much guaranteed to fail because of the security restrictions. Undoing that restriction would just create a bunch of CERT reports about Tomcat letting you browse the entire directory structure of your disk. I agree but the ../../../settings.xml was set in web.xml, under administrator control, and tomcat can't even overwrite it. We've got another problem here since Tomcat 3.3.x allow this and but Tomcat 4.1.x prevent it. Should we fix Tomcat 3.3.2 ? One of the important enablers for using external entity files in Digester is to use the Digester.parse() that takes an InputSource (rather than an InputStream), and be sure you have configured your InputSource to include the source URL. That is necessary for the XML parser to be able to resolve relative system ids. The code in ContextConfig that parses web.xml and TLD files was modified (a while back) to do this kind of thing, if you need an example. Didn't have access on it since the external entity is set in web.xml so under org.apache.catalina.startup.ContextConfig.applicationConfig control, not application control. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
On Wed, 9 Oct 2002, Henri Gomez wrote: Date: Wed, 09 Oct 2002 18:13:10 +0200 From: Henri Gomez [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: apps conversion from 3.3.1 to 4.1.12 Haven't looked at the code, but here's a couple of thoughts that might help: If your path above (../../../settings.xml) is attempting to go above the context root of the webapp, it's pretty much guaranteed to fail because of the security restrictions. Undoing that restriction would just create a bunch of CERT reports about Tomcat letting you browse the entire directory structure of your disk. I agree but the ../../../settings.xml was set in web.xml, under administrator control, and tomcat can't even overwrite it. We've got another problem here since Tomcat 3.3.x allow this and but Tomcat 4.1.x prevent it. Should we fix Tomcat 3.3.2 ? One of the important enablers for using external entity files in Digester is to use the Digester.parse() that takes an InputSource (rather than an InputStream), and be sure you have configured your InputSource to include the source URL. That is necessary for the XML parser to be able to resolve relative system ids. The code in ContextConfig that parses web.xml and TLD files was modified (a while back) to do this kind of thing, if you need an example. Didn't have access on it since the external entity is set in web.xml so under org.apache.catalina.startup.ContextConfig.applicationConfig control, not application control. If this reference is in your web.xml file, then my suggestion is already being done. To test it, try temporarily copying the settings.xml file into the WEB-INF directory and changing the relative URL appropriately. I'd be -1 on removing the security check in 4.x/5.x. Fixing 3.3.2 sounds like a good idea. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: apps conversion from 3.3.1 to 4.1.12
If this reference is in your web.xml file, then my suggestion is already being done. To test it, try temporarily copying the settings.xml file into the WEB-INF directory and changing the relative URL appropriately. Putting the file in WEB-INF works, even if I use ../settings, ie directly in webapps/ROOT. I'd be -1 on removing the security check in 4.x/5.x. Fixing 3.3.2 sounds like a good idea. I'll be -1 to fix the 3.3.2 for many reasons : - It will brake all deployment strategy - I'm still not sure it's a security problem since nobody prevent you to change to PUBLIC and goes outside : !ENTITY % settings SYSTEM ../../../settings.xml %settings; to !ENTITY % settings PUBLIC hackme http://hackme.com/settings.xml; %settings; That's more than insecure isn't it ? I take a look in specs and didn't see anything preventing you to have entities located outside WEBAPP so I feel it's a regression and not a security feature. Ad minima, in TC 4.x and 5.x, there should be a setting in web.xml, or server.xml to enable this behaviour even if it's prevented by default. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
