Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
Bill Barker wrote: Bill Barker wrote: Ok, this isn't right. Tomcat defaults to NonLoginAuthenticator if there is no login-config. This one just approves everybody for everything. Ok. This isn't absolutely critical, but needs to be fixed. I just tested this with a fresh build of everything, and it seems that Tomcat is working fine. I set allowTrace=true on the connector, and put in a security-constraint to forbid TRACE in ROOT/WEB-INF/web.xml but no login-config. The result is a perfectly good 403 response to 'TRACE / HTTP/1.0', and a perfectly good TRACE response to 'TRACE /jsp-examples/ HTTP/1.0'. I'm afraid that you will have to provide a test case if you want to re-open this issue ;-). I'm resolving it as WORKSFORME. Cool. That's the impression I had, but it wasn't a proper test, so I'm not too sure. I was surprised to notice it wasn't possible to add the constraint to the default web.xml and be done. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
Bill Barker wrote: Ok, this isn't right. Tomcat defaults to NonLoginAuthenticator if there is no login-config. This one just approves everybody for everything. Ok. This isn't absolutely critical, but needs to be fixed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, January 11, 2004 1:18 AM Subject: Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability Bill Barker wrote: Ok, this isn't right. Tomcat defaults to NonLoginAuthenticator if there is no login-config. This one just approves everybody for everything. Ok. This isn't absolutely critical, but needs to be fixed. I just tested this with a fresh build of everything, and it seems that Tomcat is working fine. I set allowTrace=true on the connector, and put in a security-constraint to forbid TRACE in ROOT/WEB-INF/web.xml but no login-config. The result is a perfectly good 403 response to 'TRACE / HTTP/1.0', and a perfectly good TRACE response to 'TRACE /jsp-examples/ HTTP/1.0'. I'm afraid that you will have to provide a test case if you want to re-open this issue ;-). I'm resolving it as WORKSFORME. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
Remy Maucherat wrote: Bill Barker wrote: I just tried this with the CVS HEAD of Tomcat 5 (after putting in a security-constraint in the ROOT web.xml) and Tomcat happily returned a 403 response. I don't care about this lame XSS bug. However, what you describe doesn't work for me. There are two issues that I can see: - if there's no auth-constraint, then it just passes through (I think it should instead return a 403 right away) - if there's no login config, then it also just passes through (I think it should instead return a 403 right away) Those are likely regressions after the rewrite of the algorithm, but it's good to find them before a release :) The idea is to fix the vulnerability by adding in conf/web.xml: !-- === Disable TRACE by default === -- security-constraint web-resource-collection web-resource-nameDisableExploitTraceHTTP/web-resource-name url-pattern/*/url-pattern http-methodTRACE/http-method /web-resource-collection /security-constraint I'll do a quick bench to see if it hurts performance, just in case (I think it doesn't as the matching is efficient). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
Remy Maucherat wrote: Remy Maucherat wrote: Bill Barker wrote: I just tried this with the CVS HEAD of Tomcat 5 (after putting in a security-constraint in the ROOT web.xml) and Tomcat happily returned a 403 response. I don't care about this lame XSS bug. However, what you describe doesn't work for me. There are two issues that I can see: - if there's no auth-constraint, then it just passes through (I think it should instead return a 403 right away) - if there's no login config, then it also just passes through (I think it should instead return a 403 right away) Those are likely regressions after the rewrite of the algorithm, but it's good to find them before a release :) The idea is to fix the vulnerability by adding in conf/web.xml: !-- === Disable TRACE by default === -- security-constraint web-resource-collection web-resource-nameDisableExploitTraceHTTP/web-resource-name url-pattern/*/url-pattern http-methodTRACE/http-method /web-resource-collection /security-constraint I'll do a quick bench to see if it hurts performance, just in case (I think it doesn't as the matching is efficient). I think I made a mistake, this should apparently be: security-constraint web-resource-collection web-resource-nameDisableExploitTraceHTTP/web-resource-name url-pattern/*/url-pattern http-methodTRACE/http-method /web-resource-collection auth-constraint/ /security-constraint Otherwise, without the empty auth-constraint, it apparently means all access (please check this is correct ;) ). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, January 10, 2004 5:24 AM Subject: Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability Remy Maucherat wrote: Bill Barker wrote: I just tried this with the CVS HEAD of Tomcat 5 (after putting in a security-constraint in the ROOT web.xml) and Tomcat happily returned a 403 response. I don't care about this lame XSS bug. However, what you describe doesn't work for me. There are two issues that I can see: - if there's no auth-constraint, then it just passes through (I think it should instead return a 403 right away) No, that's what the servlet-spec says should happen. - if there's no login config, then it also just passes through (I think it should instead return a 403 right away) I think this is a problem with the deployment (i.e. Tomcat doesn't regisiter an Autheniticator if it doesn't know which one to use). Those are likely regressions after the rewrite of the algorithm, but it's good to find them before a release :) The idea is to fix the vulnerability by adding in conf/web.xml: !-- === Disable TRACE by default === -- security-constraint web-resource-collection web-resource-nameDisableExploitTraceHTTP/web-resource-name url-pattern/*/url-pattern http-methodTRACE/http-method /web-resource-collection /security-constraint I'll do a quick bench to see if it hurts performance, just in case (I think it doesn't as the matching is efficient). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability
- Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, January 10, 2004 6:28 PM Subject: Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, January 10, 2004 5:24 AM Subject: Re: SECURITY BUG: No place to disable HTTP TRACE vulnerability Remy Maucherat wrote: Bill Barker wrote: I just tried this with the CVS HEAD of Tomcat 5 (after putting in a security-constraint in the ROOT web.xml) and Tomcat happily returned a 403 response. I don't care about this lame XSS bug. However, what you describe doesn't work for me. There are two issues that I can see: - if there's no auth-constraint, then it just passes through (I think it should instead return a 403 right away) No, that's what the servlet-spec says should happen. - if there's no login config, then it also just passes through (I think it should instead return a 403 right away) I think this is a problem with the deployment (i.e. Tomcat doesn't regisiter an Autheniticator if it doesn't know which one to use). Ok, this isn't right. Tomcat defaults to NonLoginAuthenticator if there is no login-config. This one just approves everybody for everything. Those are likely regressions after the rewrite of the algorithm, but it's good to find them before a release :) The idea is to fix the vulnerability by adding in conf/web.xml: !-- === Disable TRACE by default === -- security-constraint web-resource-collection web-resource-nameDisableExploitTraceHTTP/web-resource-name url-pattern/*/url-pattern http-methodTRACE/http-method /web-resource-collection /security-constraint I'll do a quick bench to see if it hurts performance, just in case (I think it doesn't as the matching is efficient). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: security hole on windows tomcat?
Yes, adding -Dsun.io.useCanonCaches=false to the tomcat seemed to fix the security hole I discovered on my 4.1.24 tomcat on Windows XP using JDK 1.4.2. Great job finding a solution. It's a testament to open source and cooperation. Fortunately it's JSP source it's showing and people should have anything worth seeing in their servlets or EJBs anyway. :) Paul Sundling Jeff Tulley wrote: I just wanted to make sure you saw this -- Jeanfrancois made the connection that this issue has a known workaround, so you don't have to backrev your JVM if you don't want to. I tried this on Windows XP and NetWare and it worked in both places... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/12/03 7:08:50 PM Sorry I've just realize this thread may be related to bugtraq #4895132 (thanks to Jeff for the wake up mail on tomcat-dev ;-) ). The workaround is to add the following property when starting Tomcat: -Dsun.io.useCanonCaches=false Can someone try it and let me know if it change something. If this is not working, then point me to a very simple test case and I will file a new bugtraq bug. -- Jeanfrancois Eric J. Pinnell wrote: I think at this point this might be a worthwile canidate for Sun's bugparade. At least get it on their radars (if they don't know about it already). It's interesting that the bug doesn't show up in Tomcat 4.1.27. When 1.4.2 was released 4.1.24 was the latest stable build. Regardless the JDK/appserver/whatever should never puke it's guts and spit out the source code when it gets a request it doesn't know how to deal with. Upon failure it should result in some kind of error. Sun might care about this... -e On Tue, 12 Aug 2003, Jeff Tulley wrote: It is highly possible that this is dependent on the JVM you have installed. I actually finally WAS able to see this on Windows XP, but only if Tomcat was running on JVM 1.4.2. The problem did NOT happen with 1.4.1. Of course, JVM version is the one item I left off of my poll in my email below. :) I'm trying to verify this on other OS's and track down what the actual problem is. But, if you run Tomcat on JVM 1.4.2, verify if you have this problem. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/12/03 4:10:53 PM Tomcat 4.0.6 on Win2K via direct connection to Tomcat on localhost via either port 8080 or port 80 - pages return fine without the %20 suffix, always return http 404 with the suffix. Murray -Original Message- From: Jeff Tulley [mailto:[EMAIL PROTECTED] Sent: Wednesday, 13 August 2003 02:41 To: [EMAIL PROTECTED] Subject: RE: security hole on windows tomcat? So this issue is confusing. It seems that indeed there IS an issue, though most cannot see a problem. Talking to some people off-list, it seems that some think it is a JK2 / workers2.properties issue. But I'm pretty sure that others have seen this going directly to port 8080. We probably need to take a quick poll: If you have seen this security problem of being able to view JSP source, in what scenario(s)? Tomcat version OS version Directly to Tomcat (8080) or through Apache - JK or JK2? (If you've seen the problem, please include your workers or workers2.properties file, with a .txt extension) Browser version(s) url's where this was seen or not seen If you have seen this in multiple scenarios, and not in others, please list each separately. I have NOT seen it in the following scenarios: Tomcat 4.1.18, 4.1.24, 4.1.26, 4.1.27 Windows 2000 5.00.2195 Service Pack 4 Directly to port 8080 Internet Explorer 6.0.2800.1106 with all security patches up to date I tried http://(url):8080/index.jsp%20 Tomcat 4.1.18, 4.1.24, 4.1.26, fairly standard distributions (only adding one JNDIRealm beyond the default config) Novell NetWare 6.5 Directly to port 8080, and through Apache - mod_jk.nlm Internet Explorer 6.0.2800.1106 with all security patches up to date I tried http://(url):8080/index.jsp%20 and https://(url)/tomcat/admin/index.jsp%20 Hopefully this mail gets through; I haven't been seeing my emails show up on tomcat-user for some reason (I un/resubscribed today...) It would be really good to get to the bottom of this! Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/12/03 6:02:55 AM can you turn on debugging for the default servlet(conf/web.xml) and also turn on the requestdumpervalve(server.xml) and post the log. - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: Fwd: Re: security hole on windows tomcat?
If the bug was caused by adding %20 to a page/folder in URL, then i didn't reproduce it in Tomcat 5. I got 404 (the only bad thing is that 404's don't appear to be customizable with error-page directives in web.xml). What would be a good list to watch for these kinds of bugs in Tomcat? Thanks. Paul Sundling wrote: Yes, adding -Dsun.io.useCanonCaches=false to the tomcat seemed to fix the security hole I discovered on my 4.1.24 tomcat on Windows XP using JDK 1.4.2. Great job finding a solution. It's a testament to open source and cooperation. Fortunately it's JSP source it's showing and people should have anything worth seeing in their servlets or EJBs anyway. :) Paul Sundling Jeff Tulley wrote: I just wanted to make sure you saw this -- Jeanfrancois made the connection that this issue has a known workaround, so you don't have to backrev your JVM if you don't want to. I tried this on Windows XP and NetWare and it worked in both places... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/12/03 7:08:50 PM Sorry I've just realize this thread may be related to bugtraq #4895132 (thanks to Jeff for the wake up mail on tomcat-dev ;-) ). The workaround is to add the following property when starting Tomcat: -Dsun.io.useCanonCaches=false Can someone try it and let me know if it change something. If this is not working, then point me to a very simple test case and I will file a new bugtraq bug. -- Jeanfrancois Eric J. Pinnell wrote: I think at this point this might be a worthwile canidate for Sun's bugparade. At least get it on their radars (if they don't know about it already). It's interesting that the bug doesn't show up in Tomcat 4.1.27. When 1.4.2 was released 4.1.24 was the latest stable build. Regardless the JDK/appserver/whatever should never puke it's guts and spit out the source code when it gets a request it doesn't know how to deal with. Upon failure it should result in some kind of error. Sun might care about this... -e On Tue, 12 Aug 2003, Jeff Tulley wrote: It is highly possible that this is dependent on the JVM you have installed. I actually finally WAS able to see this on Windows XP, but only if Tomcat was running on JVM 1.4.2. The problem did NOT happen with 1.4.1. Of course, JVM version is the one item I left off of my poll in my email below. :) I'm trying to verify this on other OS's and track down what the actual problem is. But, if you run Tomcat on JVM 1.4.2, verify if you have this problem. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/12/03 4:10:53 PM Tomcat 4.0.6 on Win2K via direct connection to Tomcat on localhost via either port 8080 or port 80 - pages return fine without the %20 suffix, always return http 404 with the suffix. Murray -Original Message- From: Jeff Tulley [mailto:[EMAIL PROTECTED] Sent: Wednesday, 13 August 2003 02:41 To: [EMAIL PROTECTED] Subject: RE: security hole on windows tomcat? So this issue is confusing. It seems that indeed there IS an issue, though most cannot see a problem. Talking to some people off-list, it seems that some think it is a JK2 / workers2.properties issue. But I'm pretty sure that others have seen this going directly to port 8080. We probably need to take a quick poll: If you have seen this security problem of being able to view JSP source, in what scenario(s)? Tomcat version OS version Directly to Tomcat (8080) or through Apache - JK or JK2? (If you've seen the problem, please include your workers or workers2.properties file, with a .txt extension) Browser version(s) url's where this was seen or not seen If you have seen this in multiple scenarios, and not in others, please list each separately. I have NOT seen it in the following scenarios: Tomcat 4.1.18, 4.1.24, 4.1.26, 4.1.27 Windows 2000 5.00.2195 Service Pack 4 Directly to port 8080 Internet Explorer 6.0.2800.1106 with all security patches up to date I tried http://(url):8080/index.jsp%20 Tomcat 4.1.18, 4.1.24, 4.1.26, fairly standard distributions (only adding one JNDIRealm beyond the default config) Novell NetWare 6.5 Directly to port 8080, and through Apache - mod_jk.nlm Internet Explorer 6.0.2800.1106 with all security patches up to date I tried http://(url):8080/index.jsp%20 and https://(url)/tomcat/admin/index.jsp%20 Hopefully this mail gets through; I haven't been seeing my emails show up on tomcat-user for some reason (I un/resubscribed today...) It would be really good to get to the bottom of this! Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 8/12/03 6:02:55 AM
RE: security of server.xml in tomcat
Also depends on from whom you want to hide the credentials. If it's from web client, then based on servlet specifications The files inside the WEB-INF folder cannot be accessible by the web client. If you want to protect from console access users then you can protect by defining access rights to the web deployment. ST On Mon, 2003-06-09 at 14:42, Chad Johnson wrote: Just a thought, I can't see how having the username and password in code is any more secure. Prying eyes could have equal access to both. Chad Johnson Web Services Developer WS Packaging - Wisconsin Label Tel:(920)487-6271 -Original Message- From: Mohamed Tagari [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 9:32 AM To: [EMAIL PROTECTED] Subject: security of server.xml in tomcat Hi, Is there any way of instantiating the password and username parameters for connecting to a database in the application code rather than having it as plain text in the server.xml. As having the username and password as plain text is not very secure.. Any help/information will be apprectiated.. The database will be containing sensitive information, hence all passwords and usernames have to be protected.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sri Thuraisamy [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security of server.xml in tomcat
Just a thought, I can't see how having the username and password in code is any more secure. Prying eyes could have equal access to both. Chad Johnson Web Services Developer WS Packaging - Wisconsin Label Tel:(920)487-6271 -Original Message- From: Mohamed Tagari [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 9:32 AM To: [EMAIL PROTECTED] Subject: security of server.xml in tomcat Hi, Is there any way of instantiating the password and username parameters for connecting to a database in the application code rather than having it as plain text in the server.xml. As having the username and password as plain text is not very secure.. Any help/information will be apprectiated.. The database will be containing sensitive information, hence all passwords and usernames have to be protected.. // java code Context init = new InitialContext(); Context ctx = (Context) init.lookup(java:comp/env); DataSource ds = (DataSource) ctx.lookup(jdbc/myoracle); // extract from server.xml Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/myoracle . . . parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter . . /ResourceParams mo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security of server.xml in tomcat
On Monday, June 9, 2003, at 03:31 PM, Mohamed Tagari wrote: Hi, Is there any way of instantiating the password and username parameters for connecting to a database in the application code rather than having it as plain text in the server.xml. As having the username and password as plain text is not very secure.. Any help/information will be apprectiated.. ok store the username/password as an encrypted text string and use the JAAS API to a: encrypt it in the first place, and b: read it back into the the application from the encrypted text string in the server.xml file. I was looking into this myself (not using tomcat but in another Oracle/Java project), but the time it would take for me to implement and test the secure/encrypted version (2 days including test) was deemed to be not worthwhile. C'est la vie. Kev parameter nameusername/name valuescott/value /parameter parameter namepassword/name valuetiger/value /parameter especially the default scott/tiger :) -- To be governed is to be watched over, inspected, spied on, directed, legislated... - Pierre-Joseph Proudhon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security threat with enabling invoker servlet in 4.1.12
The invoker servlet allows for anyone to call your servlets using their class names. This is not a problem as long as you are happy with that. In my case I have some internal servlets (used as a poor substitute for RMI) where I map the servlets to be under /internal/some.servlet and then protect /internal/* in my Apache web server in front of Tomcat. I don't use the invoker servlet since I want to declare exactly how my servlets are to be accessed. Martin Budi Kurniawan wrote: Hi, I've browsed the user list for this question but could not find the answer. Apologies if this is not the right question for this list. The release note in 4.1.12 says that the invoker servlet is turned off in the default web.xml for security reasons. However, in the examples app's web.xml the invoker is on. My questions are: 1. What security threat is that? 2. If it is not safe to turn it on in the default web.xml, is it safe to do so in the app web.xml? thx, budi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Security threat with enabling invoker servlet in 4.1.12
Thanks Martin, budi On Mon, 4 Nov 2002, Martin Algesten wrote: The invoker servlet allows for anyone to call your servlets using their class names. This is not a problem as long as you are happy with that. In my case I have some internal servlets (used as a poor substitute for RMI) where I map the servlets to be under /internal/some.servlet and then protect /internal/* in my Apache web server in front of Tomcat. I don't use the invoker servlet since I want to declare exactly how my servlets are to be accessed. Martin Budi Kurniawan wrote: Hi, I've browsed the user list for this question but could not find the answer. Apologies if this is not the right question for this list. The release note in 4.1.12 says that the invoker servlet is turned off in the default web.xml for security reasons. However, in the examples app's web.xml the invoker is on. My questions are: 1. What security threat is that? 2. If it is not safe to turn it on in the default web.xml, is it safe to do so in the app web.xml? thx, budi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Security threat with enabling invoker servlet in 4.1.12
-Original Message- From: Budi Kurniawan [mailto:budik;cse.unsw.EDU.AU] Sent: Friday, November 01, 2002 7:22 PM To: Tomcat Developers List Subject: Security threat with enabling invoker servlet in 4.1.12 Hi, I've browsed the user list for this question but could not find the answer. Apologies if this is not the right question for this list. The release note in 4.1.12 says that the invoker servlet is turned off in the default web.xml for security reasons. However, in the examples app's web.xml the invoker is on. My questions are: 1. What security threat is that? 2. If it is not safe to turn it on in the default web.xml, is it safe to do so in the app web.xml? thx, budi This probably is more appropriate for the user list, but to answer your question, please see http://www.mail-archive.com/tomcat-dev;jakarta.apache.org/msg33723.html and http://www.mail-archive.com/tomcat-dev;jakarta.apache.org/msg34918.html -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Security Check in Classloader.
Jean-Francois Arcand wrote:
Hi,
In StandardClassLoader, starting line 815, the SecurityManager is invoked:
// (.5) Permission to access this class when using a SecurityManager
if (securityManager != null) {
int i = name.lastIndexOf('.');
if (i = 0) {
try {
securityManager.checkPackageAccess(name.substring(0,i));
} catch (SecurityException se) {
String error = Security Violation, attempt to use +
Restricted Class: + name;
System.out.println(error);
se.printStackTrace();
log(error);
throw new ClassNotFoundException(error);
}
}
}
Why are we calling the SecurityManager.checkPackageAccess in
StandardClassLoader? Since we give all permissions to
org.apache.catalina, I think this call is useless. This call is required
when invoked inside WebappClassLoader.
Because a paranoid Tomcat admin like me may not grant AllPermission to catalina
in their security policy.
Regards,
Glenn
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Security Check in Classloader.
Foget that email. The problem is in front of the computer, not in the
class ;-)
-- Jeanfrancois
Jean-Francois Arcand wrote:
Hi,
In StandardClassLoader, starting line 815, the SecurityManager is
invoked:
// (.5) Permission to access this class when using a
SecurityManager
if (securityManager != null) {
int i = name.lastIndexOf('.');
if (i = 0) {
try {
securityManager.checkPackageAccess(name.substring(0,i));
} catch (SecurityException se) {
String error = Security Violation, attempt to use +
Restricted Class: + name;
System.out.println(error);
se.printStackTrace();
log(error);
throw new ClassNotFoundException(error);
}
}
}
Why are we calling the SecurityManager.checkPackageAccess in
StandardClassLoader? Since we give all permissions to
org.apache.catalina, I think this call is useless. This call is
required when invoked inside WebappClassLoader.
Thanks,
-- Jeanfrancois
--
To unsubscribe, e-mail:
mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [Security Audit] CoyoteRequest.doGetSession
OK, I have committed the change, do testing, and try to hack the code I just wrote. Of course, more testing will be appreciated :-) -- Jeanfrancois Glenn Nielsen wrote: Jean-Francois Arcand wrote: Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. It isn't the size of the block of code that matters... Its how the code within that block could pose a security risk. From a security standpoint I don't see any possible exploits. There may be a slight performance improvement for those requests where a session is used by moving the doPrivileged out of the critical path. From just a performance perspective I would want to profile Tomcat to determine where efforts could be best spent to improve performance. Then spend time on the biggest bottleneck to performance found rather than on this. It will require that the documentation for how to write a Manager/Store be updated to discuss this issue. It will also require alot of testing to make sure that you find _all_ the places where a doPrivileged is needed. That means trying all the Manager/Store implementations which come with Tomcat and trying different configuration options. Sounds like alot of work to me. I know I don't have the time to make a change like this for the minimal benefit I see. But if you have the time and want to implement this, go ahead, its your itch. :-) Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [Security Audit] CoyoteRequest.doGetSession
The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. -1 for changing/removing the doPrivileged() Regards, Glenn Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- 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: [Security Audit] CoyoteRequest.doGetSession
Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented somewhere since Manager written for Tomcat 4 may no longer works. The catalina.policy file can then be used to give special privileges to ManagerX, but not to ManagerY (same for Store instance or whatever objects is used), based on codebase. Any recommendations/objections to the modification? Thanks, -- Jeanfrancois P.S Right now, if you run Tomcat with the default Security manager, the doPrivilege block is useless. For performance reason, we should avoid this call. -- 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] -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] CoyoteRequest.doGetSession
Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Persisting session data is the responsibility of the container not the web application. Session management/persistence should be completely transparent to the webapp including security policy permissions required for managing/persisting those sessions. Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required) uses a o.a.c.Store object . The Manager and the Store object may need special privileges when handling session persistance (see o.a.c.session.FileStore for an example). I would recommend we remove the doPrivilege block from CoyoteRequest and delegate the doPrivilege call to the Manager (or the Store) instance. That will allow better fine grained security check. Only the required operations should be granted (right now every Manager is granted - so every Store instance!). As an example, o.a.c.session.FileStore does not contains any security checks in its current implementation, and IMO, it should. The contract between the Manager and CoyoteRequest will have to be documented
Re: [Security Audit] CoyoteRequest.doGetSession
Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. -- Jeanfrancois I also thing that the permissions should be granted on apps, not managers. The manager should check and have control over the operation that it's doing. ( for example give only some applications permissions to serialize the session in a file - that's probably a bad example as using security manager for that is not the best implementation, but I think you get my point ). Persisting session data is the responsibility of the container not the web application. Session management/persistence should be completely transparent to the webapp including security policy permissions required for managing/persisting those sessions. Costin Jean-Francois Arcand wrote: Glenn Nielsen wrote: The doPrivileged() for getting a session is in the CoyoteRequest public getSession() method which is implemented as required by ServletRequest and HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. The getSession() can be called by a web application. The doPrivileged() block would be required to exist either where it currently is or in each individual implementation of Manager/Store. If it wasn't there getting a session would fail if the web app were not granted the necessary permissions. Permissions I would not want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. IMHO it is best left where it is. If someone were to implement a custom Manager/Store then the permissions allowed at that point would be the intersection of those permissions granted to catalina and those granted to the codeBase for the custom Manager/Store. So you still have your fine grained control of security policies. That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? -1 for changing/removing the doPrivileged() Other voices? Regards, Glenn Thanks, -- Jeanfrancois Jean-Francois Arcand wrote: Hi, In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege block that grant the doGetSession method. This method delegate the logic to the o.a.c.Manager instance. A Manager can (but it's not required)
Re: security
On Wed, 2002-10-16 at 17:12, Costin Manolache wrote:
Bob Herrmann wrote:
Looking into the Tomcat jars, I noticed the package org.apache.jk
isn't blocked... so even with the Security Manager running, I think I am
able to get catalina to load arbitrary classes like this,
%
org.apache.jk.apr.TomcatStarter.mainClasses = new String[]{
someClass };
org.apache.jk.apr.TomcatStarter.main(new String[0]);
%
So, My question is, should we block access to package org.apache.jk
from webapps?
Bob,
This won't change the security rules or context in any way. If you
are able to create 'someClass', you can call it directly. If
you call it via TomcatStarter - there is no difference as long
as no doPriviledged block is reached ( since the security context
is the intersection of all callers - and this call is originated
from user code ).
I am a tad fuzzy on this security stuff... but if the system class
loader is (or a higher privileged class loader has loaded the
TomcatStarter class), then wont the Class.forName() that it does
bypass the possible webapp restriction on class loading... (for example
the webapp classloader restricts accessing org.apache.catalina.*)
I also think jk is loaded in the server loader - so it shouldn't be
visible.
My jsp page compiles and seems to invoke the TomcatStarter
Please, lets wait few more days for commiter list creation and use it
for this kind of discussions. If this would be a real exploit, it would be
much better to have the information public _after_ a fix is commited.
ok.
Cheers,
-bob
We can forward all the mails to tomcat-dev with a small delay and
nothing will be lost. If a problem is real, we can fix it first
and then bounce the message. If not - we can just bounce them
after we find it is harmless.
--
Costin
--
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: [Security Audit] CoyoteRequest.doGetSession
Jean-Francois Arcand wrote: Glenn Nielsen wrote: Costin Manolache wrote: I'm in the middle on this one - but I would vote for Jean-Francois proposal. Glen is right, it is possible to restrict individual managers using the policy. However as geenral programming it is better to keep the doPrivileged block as small as possible - and have each individual manager that needs to change the permission context do that for the specific areas where this is needed, instead of a global aproach. In general I agree, keeping the amount of code within a doPrivileged() block to a minimum is a good practice. That makes it less likely that the code which calls a method which uses doPrivileged can compromise security. That is not the case for getSession() where the only thing passed to the method is a boolean for create and the Manager gets the JSESSIONID cookie from the request. Removing doPrivileged() from where it currently is will force alot of other work to be done. And will then require anyone who implements a custom Manager/Store to wrap their code in doPrivileged() also. I don't see any security risks from the current implemenation, so why change it? If you can show me an exploit that this change would fix I would be all for it. Eum...why waiting for a security issue (joke: we are not Microsoft ;-) ). Spending time trying to demonstrate a security hole will take as much time as reducing the doPrivilege block. I understand your point but still, I consider the doPrivilege block too large. And still, when Tomcat is used as it is (with the default SecurityManager), the doPrivilege block is *not* required. For a lot of Tomcat users, we are forcing a doPrivilege block. Correct me if I'm wrong, but only JDBCStore and FileStore needs to be changed. I volonteer to make the extra work. It isn't the size of the block of code that matters... Its how the code within that block could pose a security risk. From a security standpoint I don't see any possible exploits. There may be a slight performance improvement for those requests where a session is used by moving the doPrivileged out of the critical path. From just a performance perspective I would want to profile Tomcat to determine where efforts could be best spent to improve performance. Then spend time on the biggest bottleneck to performance found rather than on this. It will require that the documentation for how to write a Manager/Store be updated to discuss this issue. It will also require alot of testing to make sure that you find _all_ the places where a doPrivileged is needed. That means trying all the Manager/Store implementations which come with Tomcat and trying different configuration options. Sounds like alot of work to me. I know I don't have the time to make a change like this for the minimal benefit I see. But if you have the time and want to implement this, go ahead, its your itch. :-) Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] Package protection...
IMO sealing is the best protection against insertion,
and using URLClassLoader ( or making sure all the checks from
URLClassLoader are reproduced ).
I agree, this is a potential risk - as untrusted code may access
package fields. So far I don't see any, but better to be sure.
Costin
Jean-Francois Arcand wrote:
HI,
is somebody aware why package org.apache.coyote.* and
org.apache.tomcat.* are not protected againts package insertion/access
in Catalina.java. What is the reasons? Actually, classes are not
available to a Webapp (the Classloader is taking care of it) but when
Tomcat is embedded in an app container (or when there is a special
Classloader), those classes are available :-(
Actually, we only protect the following package:
if( System.getSecurityManager() != null ) {
String access = Security.getProperty(package.access);
if( access != null access.length() 0 )
access += ,;
else
access = sun.,;
Security.setProperty(package.access,
access + org.apache.catalina.,org.apache.jasper.);
String definition =
Security.getProperty(package.definition); if( definition !=
null definition.length() 0 )
definition += ,;
else
definition = sun.,;
Security.setProperty(package.definition,
// FIX ME package javax. was removed to prevent HotSpot
// fatal internal errors
definition +
java.,org.apache.catalina.,org.apache.jasper.);
}
Thanks,
-- Jeanfrancois
--
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Security Audit] Package protection...
I agree that both of those packages should be protected.
Why they are not included? org.apache.coyote is most likely missing
because it is a relatively new package. org.apache.util may just have
been missed.
The code below is in both startup/Catalina.java and startup/CatalinaService.java
I will go ahead and patch this in Tomcat 4 HEAD.
Regards,
Glenn
Jean-Francois Arcand wrote:
HI,
is somebody aware why package org.apache.coyote.* and
org.apache.tomcat.* are not protected againts package insertion/access
in Catalina.java. What is the reasons? Actually, classes are not
available to a Webapp (the Classloader is taking care of it) but when
Tomcat is embedded in an app container (or when there is a special
Classloader), those classes are available :-(
Actually, we only protect the following package:
if( System.getSecurityManager() != null ) {
String access = Security.getProperty(package.access);
if( access != null access.length() 0 )
access += ,;
else
access = sun.,;
Security.setProperty(package.access,
access + org.apache.catalina.,org.apache.jasper.);
String definition = Security.getProperty(package.definition);
if( definition != null definition.length() 0 )
definition += ,;
else
definition = sun.,;
Security.setProperty(package.definition,
// FIX ME package javax. was removed to prevent HotSpot
// fatal internal errors
definition +
java.,org.apache.catalina.,org.apache.jasper.);
}
Thanks,
-- Jeanfrancois
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Bojan Smojver wrote: Quoting Bill Barker [EMAIL PROTECTED]: I'm agreeing with Costin. Please move this discussion to [EMAIL PROTECTED] It is off-topic here. Promise not to write a single byte on this topic on Tomcat-Dev list after this e-mail. Please don't missunderstand this - I have nothing against velocity, it is a nice tool ( I like the introspection/bean EL - I hope the jsp el will be close and I'm following the developments in commons ). There are many cases where its simplicity is a benefit, and for standalone use jsp can't be used. The problem is - this list is for servlet and jsp development. And I personally don't like the idea of treating the users ( web developers or not ) as stupid that shouln't have powerfull tools because they may do bad things. If you feel a need to convert people to velocity - I sugest you subscribe to Perl and PHP mailing lists ( and maybe ASP ? ). Maybe they'll apreciate this kind of arguments :-) Costin Bojan - This mail sent through IMP: http://horde.org/imp/ -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity (was RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability)
Bojan,
Just move the code you wrote into a context object, reference it and
poof! Velocity gets OutOfMemory, too. Bad code is limited to front ends.
Velocity is nice. It is an excellent project, and Geir is possibly the
most responsive and helpful project leader I have ever encountered.
But there IS programming in a Velocity page--it's just in Yet Another
Templating Language, one that both your developers and your web
designers have to learn. That creates opportunities for confusion.
(Especially where velocimacros are involved.)
-Original Message-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 10:34 PM
To: Tomcat Developers List
Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source
disclosure vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that -
firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom =
)
#foreach( $i in [-2147483648..2147483648] ) #set($oom =
$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom ) #end
Bad code can kill ANY system for the determined(disgruntled)
developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my
clients' JSP's
on my
server
and a web designer puts this in (BTW, he wasn't forced, he simply
decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Don't buy all the velocity hype.. It is not as great as they make it out to be. Please no flames from the velocity disiples as I will not respond. -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:23 PM To: Tomcat Dev List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability On Wed, 2002-09-25 at 07:31, Matt Fury wrote: What's easier though? Upgrading a Tomcat server with a patch or re-architecting your whole site to accomodate for Velocity?? Short term, upgrading Tomcat. Long term, doing it in Velocity. Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev- [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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Yes I agree that some sort of JSP Tagging can be
beneficial but at times it is overkill. I think the
ultimate solution would be a combination of both.
--- Bojan Smojver [EMAIL PROTECTED] wrote:
On Wed, 2002-09-25 at 07:31, Matt Fury wrote:
What's easier though? Upgrading a Tomcat server
with a
patch or re-architecting your whole site to
accomodate
for Velocity??
Short term, upgrading Tomcat. Long term, doing it in
Velocity.
Bojan
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
=
int myName() {
cout -Matt Fury \n;
return 0;
}
__
Do you Yahoo!?
New DSL Internet Access from SBC Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Jon Scott Stevens wrote: Unlike JSP, we don't store (or encourage people to store) .vm files in the webroot. They can be anywhere on the fileystem and with custom resource loaders could even be stored in a database on another machine somewhere. Well, this is not a very good policy IMO. Self-contained applications are a good thing ( IMO ). And of course, JSPs don't have to be stored in the webroot either - and in general shouldn't be there except for development. It's better (IMO) to just precompile and include only the generated servlets - at least for a category of webapps. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/25 6:27 AM, Costin Manolache [EMAIL PROTECTED] wrote: Well, this is not a very good policy IMO. Self-contained applications are a good thing ( IMO ). Then store your templates in the WEB-INF directory. That is what we do with Scarab, which is 100% self contained. And of course, JSPs don't have to be stored in the webroot either - and in general shouldn't be there except for development. It's better (IMO) to just precompile and include only the generated servlets - at least for a category of webapps. Correct, but what is *encouraged* by default is to store them in the webroot. Maybe you guys should fix that. jakarta-tomcat-4.0.5/webapps/examples/jsp -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Wed, 2002-09-25 at 20:59, John Trollinger wrote: Don't buy all the velocity hype.. It is not as great as they make it out to be. What hype? I don't follow here... Velocity is just a template language, plain, simple and relatively small. It's greatness comes from the fact that you cannot do things in it, not from that fact that you can. Other template languages might be as good or better, wouldn't know, but given that Velocity is a Jakarta project, it seemed like a reasonable suggestion to me. And it certainly does the job for me. I don't see why would sharing a good experience with someone qualify as hype. But all that is actually beside the point. The point is that you don't want your web designers to touch Java code, ever. Making web pages programs, with access into depths of you JVM, is what the initial problem with JSP's actually is. Please no flames from the velocity disiples as I will not respond. Why do you think anyone from Velocity crowd would flame you? I found most users and developers to be helpful and constructive. They certainly helped me switch from JSP's in no time at all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Bojan Smojver wrote: On Wed, 2002-09-25 at 20:59, John Trollinger wrote: Don't buy all the velocity hype.. It is not as great as they make it out to be. What hype? I don't follow here... Velocity is just a template language, plain, simple and relatively small. It's greatness comes from the fact that you cannot do things in ... And Velocity does have a mailing list where all this can be discussed. This is tomcat-dev - for servlet and jsp development. If you have any ideas on how to improve jasper - great, but please don't waste our time with off topic subjects. Comments and sugestions on JSP spec can be addressed to the feedback address from Sun, we just implement it. ( and BTW, nobody forces you to use any java inside the JSP if you don't want to, or any of the features that are specific to jsps. ) Costin ( who enjoys writing java inside jsps, and thinks web applications _are_ programs, regardless of what other people claim ). it, not from that fact that you can. Other template languages might be as good or better, wouldn't know, but given that Velocity is a Jakarta project, it seemed like a reasonable suggestion to me. And it certainly does the job for me. I don't see why would sharing a good experience with someone qualify as hype. But all that is actually beside the point. The point is that you don't want your web designers to touch Java code, ever. Making web pages programs, with access into depths of you JVM, is what the initial problem with JSP's actually is. Please no flames from the velocity disiples as I will not respond. Why do you think anyone from Velocity crowd would flame you? I found most users and developers to be helpful and constructive. They certainly helped me switch from JSP's in no time at all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Costin Manolache [EMAIL PROTECTED]:
And Velocity does have a mailing list where all this can be discussed.
This is tomcat-dev - for servlet and jsp development.
If you have any ideas on how to improve jasper - great, but please don't
waste our time with off topic subjects. Comments and sugestions on JSP spec
can be addressed to the feedback address from Sun, we just implement it.
( and BTW, nobody forces you to use any java inside the JSP if you don't
want to, or any of the features that are specific to jsps. )
All right then, let's talk about JSP's. If I host my clients' JSP's on my server
and a web designer puts this in (BTW, he wasn't forced, he simply decided he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
What would happen to my Tomcat? I think this is called OutOfMemoryError and it
would affect every single web application running in that instance of Tomcat,
possibly owned by some other clients of mine. Completely unacceptable...
Web applications are collection programs and other stuff, for instance web
pages. However, web pages should not be programs because they are (usually)
maintained by non-programmers. The fact that you know what you're doing doesn't
exuse the shortcomings of the technology.
Bojan
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
With power comes responsibility.
% System.exit(1) %
-bob
P.S. Yea, I know the SecurityManager can catch this, if enabled.
On Wed, 2002-09-25 at 21:22, Bojan Smojver wrote:
Quoting Costin Manolache [EMAIL PROTECTED]:
And Velocity does have a mailing list where all this can be discussed.
This is tomcat-dev - for servlet and jsp development.
If you have any ideas on how to improve jasper - great, but please don't
waste our time with off topic subjects. Comments and sugestions on JSP spec
can be addressed to the feedback address from Sun, we just implement it.
( and BTW, nobody forces you to use any java inside the JSP if you don't
want to, or any of the features that are specific to jsps. )
All right then, let's talk about JSP's. If I host my clients' JSP's on my server
and a web designer puts this in (BTW, he wasn't forced, he simply decided he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
What would happen to my Tomcat? I think this is called OutOfMemoryError and it
would affect every single web application running in that instance of Tomcat,
possibly owned by some other clients of mine. Completely unacceptable...
Web applications are collection programs and other stuff, for instance web
pages. However, web pages should not be programs because they are (usually)
maintained by non-programmers. The fact that you know what you're doing doesn't
exuse the shortcomings of the technology.
Bojan
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Bob Herrmann [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on my server
and a web designer puts this in (BTW, he wasn't forced, he simply decided he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on my
server
and a web designer puts this in (BTW, he wasn't forced, he simply decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Bojan Smojver wrote: All right then, let's talk about JSP's. If I host my clients' JSP's on my server and a web designer puts this in (BTW, he wasn't forced, he simply decided he wanted to do it): And your proposed solution is ... ? Do you have a patch to solve this problem ? If so, send the code. IF not - please let me know what's your point here ? Do you think we're stupid and never heard about denial of service ? BTW, velocity _is_ a programming language - at least by the book definition, AFAIK it is turing complete. Some things are more difficult to do, but not impossible - you can see it as a benefit, I see it as a major lack of flexibility. So if you want to discuss solutions for this problem - I'm sure it'll help other templating and programming tools as well, including velocity ( which BTW can be a nice tool - and the lack of flexibility can be good in some cases ). I don't know what to do about your web designer - who doesn't know programming but decides to write some DOS code in his page. But I know that the best web applications I've used so far ( including some in php or perl ) were written by people who know a lot of programming. You need software engineers, useability engineers - not web designers who are clueless on programming ( and can't be trusted to not write DOS just for fun ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
I'm agreeing with Costin. Please move this discussion to
[EMAIL PROTECTED] It is off-topic here.
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 25, 2002 7:33 PM
Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on
my
server
and a web designer puts this in (BTW, he wasn't forced, he simply
decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
-
This mail sent through IMP: http://horde.org/imp/
--
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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Costin Manolache [EMAIL PROTECTED]: Bojan Smojver wrote: All right then, let's talk about JSP's. If I host my clients' JSP's on my server and a web designer puts this in (BTW, he wasn't forced, he simply decided he wanted to do it): And your proposed solution is ... ? Don't use JSP's. I think that was very clear from the beginning of this thread. Do you have a patch to solve this problem ? If so, send the code. IF not - please let me know what's your point here ? Do you think we're stupid and never heard about denial of service ? No, I don't think that anyone here is stupid - how did you get that idea? And I don't have a patch. I don't think anyone has. Furthermore, since this is not my itch any more, why would I scratch? Also I don't think that malicious people can be prevented from causing problems if they really want to. But, if you make it easy for it to happen by accident to the people that don't really understand what they're doing, that's asking for trouble (e.g. how many web designer really understand the concept of session beans?). My point is this - JSP makes it dead easy to not write MVC applications and to fiddle with Java code where you shouldn't. Jon explained it here: http://jakarta.apache.org/velocity/ymtd/ymtd.html. Bottom line: let designers design and let programmers program. BTW, velocity _is_ a programming language - at least by the book definition, AFAIK it is turing complete. Some things are more difficult to do, but not impossible - you can see it as a benefit, I see it as a major lack of flexibility. Actually, I think even Velocity can do too much. An even better template language (or whatever you want to name it - don't really care) wouldn't allow method calls etc. But that's a different story altogether... So if you want to discuss solutions for this problem - I'm sure it'll help other templating and programming tools as well, including velocity ( which BTW can be a nice tool - and the lack of flexibility can be good in some cases ). I don't know what to do about your web designer - who doesn't know programming but decides to write some DOS code in his page. But I know that the best web applications I've used so far ( including some in php or perl ) were written by people who know a lot of programming. You need software engineers, useability engineers - not web designers who are clueless on programming ( and can't be trusted to not write DOS just for fun ). I'm not talking about my web designer, I'm talking about my clients' web designers. I cannot fire my clients' employees. I also don't have any influence over what they do and don't know, how qualified they are and if they care. Again, the point is - why give people power (that they don't need anyway) and hope nothing bad will happen? Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Bill Barker [EMAIL PROTECTED]: I'm agreeing with Costin. Please move this discussion to [EMAIL PROTECTED] It is off-topic here. Promise not to write a single byte on this topic on Tomcat-Dev list after this e-mail. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Would the following be vulnerable? 1) Use Jk only 2) do NOT use -- JkMount /servlet/* loadbalancer 3) But the invoker mapping is enabled Would they be vulnerable? I personally don't see a security flaw in this config. But does Jk also look for the text jsessionid being passed in the URL and automagically pass it along to tomcat? AFAIK - I thought a Rewrite rule needed to be added to have that behavior. Remy Maucherat wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. This particular configuration is available in the default Tomcat configuration. Workarounds --- An easy workaround exists for existing Tomcat installations, by disabling the invoker servlet in the default webapp configuration. In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping Releases The Apache Tomcat Team announces the immediate availability of new releases which include a fix to the invoker servlet. Apache Tomcat 4.1.12 Stable: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ Apache Tomcat 4.0.5: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ Remy -- 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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Evil question: does this vulnerability exist in Tomcat 3.2.3? Mitchell Evan Marx[EMAIL PROTECTED] ATT IP Network Configuration Provisioning Development -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 7:59 AM To: Tomcat Developers List; Tomcat Users List; announcements Subject: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. This particular configuration is available in the default Tomcat configuration. Workarounds --- An easy workaround exists for existing Tomcat installations, by disabling the invoker servlet in the default webapp configuration. In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping Releases The Apache Tomcat Team announces the immediate availability of new releases which include a fix to the invoker servlet. Apache Tomcat 4.1.12 Stable: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ Apache Tomcat 4.0.5: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ Remy -- 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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Tim Funk wrote: Would the following be vulnerable? 1) Use Jk only 2) do NOT use -- JkMount /servlet/* loadbalancer 3) But the invoker mapping is enabled Would they be vulnerable? I personally don't see a security flaw in this config. But does Jk also look for the text jsessionid being passed in the URL and automagically pass it along to tomcat? AFAIK - I thought a Rewrite rule needed to be added to have that behavior. If you do end up passing any context/servlet/* URLs to Tomcat, then you're safe. However, I would still edit conf/web.xml as explained in the advisory to make sure there are no problems in the future. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Remy Maucherat wrote: Tim Funk wrote: Would the following be vulnerable? 1) Use Jk only 2) do NOT use -- JkMount /servlet/* loadbalancer 3) But the invoker mapping is enabled Would they be vulnerable? I personally don't see a security flaw in this config. But does Jk also look for the text jsessionid being passed in the URL and automagically pass it along to tomcat? AFAIK - I thought a Rewrite rule needed to be added to have that behavior. If you do end up passing any context/servlet/* URLs to Tomcat, then you're safe. However, I would still edit conf/web.xml as explained in the advisory to make sure there are no problems in the future. Of course, this should read If you do NOT end up ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Marx, Mitchell E (Mitch), ALCNS wrote: Evil question: does this vulnerability exist in Tomcat 3.2.3? No. At worst it would be vulnerable to a distant cousin of the exploit. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
This may be true (though I have never tested it).
What's easier though? Upgrading a Tomcat server with a
patch or re-architecting your whole site to accomodate
for Velocity??
;-)
-Matt
--- Jon Scott Stevens [EMAIL PROTECTED] wrote:
on 2002/9/24 4:59 AM, Remy Maucherat
[EMAIL PROTECTED] wrote:
A security vulnerability has been confirmed to
exist in all Apache
Tomcat 4.x releases (including Tomcat 4.0.4 and
Tomcat 4.1.10), which
allows to use a specially crafted URL to return
the unprocessed source
of a JSP page, or, under special circumstances, a
static resource which
would otherwise have been protected by security
constraint, without the
need for being properly authenticated.
Once again...JSP sucks and Velocity is the right way
to go...you will never
have to worry about your container spilling your
beans (pun intended).
Given that Tomcat gets around 100k+
downloads/week...imagine how many
servers now need to be updated and how much money
and time that will cost to
do so?
http://jakarta.apache.org/velocity/
Wake up people. Velocity is faster and more secure
than JSP will ever be.
-jon
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
=
int myName() {
cout -Matt Fury \n;
return 0;
}
__
Do you Yahoo!?
New DSL Internet Access from SBC Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
This list is for discussing Tomcat development, not velocity, web macro, et. al. The evangelizing for velocity is off topic in this list. JSP is part of Tomcat, live with it and move on. There are plenty of other forums for discussing the merits of one web templating technology vs another. Thanks, Glenn Bojan Smojver wrote: On Wed, 2002-09-25 at 07:31, Matt Fury wrote: What's easier though? Upgrading a Tomcat server with a patch or re-architecting your whole site to accomodate for Velocity?? Short term, upgrading Tomcat. Long term, doing it in Velocity. Bojan -- 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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Tuesday 24 September 2002 05:26 pm, Jon Scott Stevens wrote: on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Perhaps you would prefer this exploit? http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm Horrors! Velocity is insecure! The DefaultServlet exploit is a general security problem in Tomcat. JSP may be somewhat more vulnerable, due to the (somewhat naieve) expectation that the source will be confidential, but it's not really JSP per se that is at fault. I wonder what could be done with the CGIServlet, for example. The root cause is the InvokerServlet. It's inherently insecure. It can be used not just to execute an arbitrary servlet, but to actually load any java class. And loading a class is not side-effect free. Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. As long as it's running on an insecure container, it's really no safer. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/24 5:15 PM, Steve Downey [EMAIL PROTECTED] wrote: http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultS ervlet/sample.vm Unlike JSP, we don't store (or encourage people to store) .vm files in the webroot. They can be anywhere on the fileystem and with custom resource loaders could even be stored in a database on another machine somewhere. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Glenn Nielsen [EMAIL PROTECTED]: This list is for discussing Tomcat development, not velocity, web macro, et. al. The evangelizing for velocity is off topic in this list. JSP is part of Tomcat, live with it and move on. There are plenty of other forums for discussing the merits of one web templating technology vs another. Sure. But it's fun :-) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Steve Downey [EMAIL PROTECTED]: Perhaps you would prefer this exploit? http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm Horrors! Velocity is insecure! The DefaultServlet exploit is a general security problem in Tomcat. JSP may be somewhat more vulnerable, due to the (somewhat naieve) expectation that the source will be confidential, but it's not really JSP per se that is at fault. Actually, there is a big difference here. You're assuming that Velocity macro pages are programs (well, classes) like JSP's and therefore probably contain security sensitive information. Usually what you'll see is something like this: #foreach($role in $roles) #if($fields.rolename $fields.rolename==$role.rolename) option selected=selected$role.rolename/option #else option$role.rolename/option #end #end This is a (very typical) snippet from a VM that does editing of Tomcat users/roles database in one of my applications. I don't care if people see that code at all because the template doesn't do anything but templating. The beef if elsewhere (i.e. MVC). Bojan PS. Glenn, my apologies, I was just answering a direct question. - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] More information on Tomcat 4.0.3
Heads up Tomcatters ... Richard Remy Maucherat wrote: After additional review, it has been discovered that the security bug fixed in Tomcat 4.0.3 was more severe than originally though, and can be used to remotely browse the server filesystem. To exploit this bug, an attacker would require that some user modifiable data (like a form POST data, or a URL) is directly used by a servlet or JSP in a request dispatcher forward or include. It can be hard to determine if an installation of Tomcat is vulnerable to this exploit, as it depends on the web applications installed. IMPORTANT NOTE: The default Tomcat installation is NOT vulnerable to this bug. Because of this, it is HIGHLY recommended that all Tomcat 4.0.x users either: - Apply the binary patch which is available at http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2/bin/hotfi x/ Note: This particular patch can be applied on all official 4.0.x releases (including 4.0, 4.0.1 and 4.0.2). - Upgrade to Tomcat 4.0.3. - Upgrade to Tomcat 4.0.4 Beta 1. Bugzilla report on this problem: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6772 Remy -- 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: Security in Tomcat Webapps - WAS: Tomcat 4 / mod_webapp RPMsavailable...
Heres a copy of the SPEC for mod_webapp.
I'll pull together the other SPEC and init files for tomcat4 in the
future.
-thanks,
Mark Diggory
%define buildap20 0
Summary:mod_webapp modules for apache
Name: mod_webapp
Version:1.0.2
Release:1
Vendor: Apache Software Foundation
Group: System Environment/Daemons
Copyright: Apache
Url:http://jakarta.apache.org
Requires: apache, ed
BuildRequires: apache-devel, libtool
%if %{buildap20}
Requires: apache2
BuildRequires: apache2-devel
%endif
Source:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0/src/webapp-module-1.0.2-tc402-src.tar.gz
BuildRoot: /var/tmp/%{name}-root
Packager: Henri Gomez [EMAIL PROTECTED]
%description
mod_webapp is the Tomcat 4 connector for apache
%prep
rm -rf $RPM_BUILD_ROOT
rm -rf $RPM_BUILD_DIR/%{name}
%setup -n webapp-module-1.0.2-tc402
%build
# remove config.cache we shoudln't be there
rm -f apr/config.cache
support/buildconf.sh
./configure --with-apxs=/usr/sbin/apxs LIBTOOL
make
%if %{buildap20}
# remove config.cache we shoudln't be there
# rm -f apr/config.cache
./configure --with-apxs=/usr/sbin/apxs2
make
%endif
%install
mkdir -p $RPM_BUILD_ROOT/usr/lib/apache
mkdir -p $RPM_BUILD_ROOT/etc/httpd/conf
install apache-1.3/mod_webapp.so $RPM_BUILD_ROOT/usr/lib/apache
%if %{buildap20}
mkdir -p $RPM_BUILD_ROOT/etc/httpd2/conf
install apache-2.0/mod_webapp.so $RPM_BUILD_ROOT/usr/lib/apache2
%endif
%clean
rm -rf $RPM_BUILD_ROOT
%post
if [ -f /etc/httpd/conf/httpd.conf ] ; then
# 6.2 std apache layout
if ! grep -q '.*LoadModule *webapp_module *modules/mod_webapp.so'
/etc/httpd/conf/httpd.conf ; then
sed s|^\LoadModule *rewrite_module *modules/mod_rewrite.so\$|LoadModule
webapp_module modules/mod_webapp.so\\
LoadModule rewrite_module modules/mod_rewrite.so| /etc/httpd/conf/httpd.conf
/etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
# mod_ssl apache layout
if ! grep -q '.*LoadModule *webapp_module *lib/apache/mod_webapp.so'
/etc/httpd/conf/httpd.conf ; then
sed s|^\LoadModule *rewrite_module *lib/apache/mod_rewrite.so\$|LoadModule
webapp_module lib/apache/mod_webapp.so\\
LoadModule rewrite_module lib/apache/mod_rewrite.so| /etc/httpd/conf/httpd.conf
/etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
if ! grep -q '.*AddModule *mod_webapp.c' /etc/httpd/conf/httpd.conf ; then
sed s|^\AddModule *mod_rewrite.c\$|AddModule mod_webapp.c\\
AddModule mod_rewrite.c| /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
if ! grep -q '.*IfModule mod_webapp.c' /etc/httpd/conf/httpd.conf ; then
cat /etc/httpd/conf/httpd.confEOT
IfModule mod_webapp.c
WebAppConnection warpConnection warp localhost:8008
WebAppDeploy examples warpConnection /examples/
WebAppDeploy manager warpConnection /manager/
WebAppDeploy webdav warpConnection /webdav/
/IfModule
EOT
fi
# added by Mark R. Diggory and Leonid Andreev
if ! grep -iq '^servername' /etc/httpd/conf/httpd.conf ; then
sed 's/^IfModule mod_webapp.c.*$/ \
ServerName '`hostname --fqdn`'/i' /etc/httpd/conf/httpd.conf
/etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
if ! grep -iq '^directoryindex.*index\.jsp' /etc/httpd/conf/httpd.conf ; then
sed 's/^DirectoryIndex.*$/ index.jsp/' /etc/httpd/conf/httpd.conf
/etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
# end
fi
%if %{buildap20}
if [ -f /etc/httpd2/conf/httpd2.conf ] ; then
# apache2 layout (from my falsehope RPM)
if ! grep -q '.*LoadModule *webapp_module *lib/apache2/mod_webapp.so'
/etc/httpd/conf/httpd.conf ; then
sed s|^\LoadModule *rewrite_module *lib/apache2/mod_rewrite.so\$|LoadModule
webapp_module lib/apache2/mod_webapp.so\\
LoadModule rewrite_module lib/apache2/mod_rewrite.so|
/etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
if ! grep -q '.*AddModule *mod_webapp.c' /etc/httpd/conf/httpd.conf ; then
sed s|^\AddModule *mod_rewrite.c\$|AddModule mod_webapp.c\\
AddModule mod_rewrite.c| /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf-
mv -f /etc/httpd/conf/httpd.conf- /etc/httpd/conf/httpd.conf
fi
if ! grep -q '.*IfModule mod_webapp.c' /etc/httpd/conf/httpd.conf ; then
cat /etc/httpd/conf/httpd.confEOT
IfModule mod_webapp.c
WebAppConnection conn warp localhost:8008
WebAppDeploy examples conn /examples
WebAppDeploy
Re: security
Please ask this kind of question on the TOMCAT-USER list. See http://jakarta.apache.org/site/mail.html for subscription information, and a description of what questions are appropriate on what lists. Craig McClanahan On Fri, 2 Nov 2001, sihem wrote: Date: Fri, 2 Nov 2001 12:28:10 +0100 (CET) From: sihem [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: security Hi! I am trying to protect the access to my servlets from a browser. I used the code below in web.xml. Te user is correctly authenticated (for exemple, when he wants to access www.mydomain.com/servlet/HelloServlet). But afterwards, Tomcat does not find the corresponding servlet (page cannot be found) , which is curious because it finds it when there is no authentication. In tomcat.log, there is this error message : Context log: path= Error/loop in default error handler R( + /servlet + /AdminServlet) 401 null null Please, Can someone tell what is missing in my configuration ? Thanks you by advance for your help! Sihem ?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; web-app security-constraint web-resource-collection web-resource-namesecretprotect/web-resource-name url-pattern/servlet/*/url-pattern http-methodGET/http-method /web-resource-collection auth-constraint role-namewebmaster/role-name /auth-constraint /security-constraint login-config auth-method BASIC /auth-method realm-name test /realm-name /login-config /web-app ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr -- 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: Security Manager, Embedded and Class Loading
This is actually pretty easy to understand.
When you do something like
StandardEngine engine = ...;
System.out.println(My engine is + engine);
Java automatically calls engine.toString() for you. Most (but not quite
all, obviously) of the core Catalina components override toString() to
print out something reasonable. If you get
StandardEngine[null]
that just means you have not called engine.getName() yet -- afterwards, it
will print whatever name you've assigned it inside the square brackets.
Craig
On Tue, 4 Sep 2001, Nick Betteridge wrote:
Date: Tue, 04 Sep 2001 18:27:10 +0100
From: Nick Betteridge [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Security Manager, Embedded and Class Loading
I've a problem that I don't really understand.
I'm in the process of getting the security manager to work with an
Embedded setup and the bootstrap is virtually the same as Catalina's.
If I create, for example, a (Standard)Server and (Standard)Service, I
get objects generated. If I attempt to create an engine, the classloader
(catalinaLoader) finds the (Standard)Engine class, but is unable to
create a newInstance.
ie ...
/**
* Create a new server instance.
*/
public void serverCreate() {
try {
Class serverClass =
catalinaClassLoader.loadClass(org.apache.catalina.core.StandardServer);
Object server = serverClass.newInstance();
} catch (Exception ex) {
}
}
... will create a : org.apache.catalina.core.StandardServer@5d56d5
but a
public void engineCreate() {
try {
Class engineClass =
catalinaClassLoader.loadClass(org.apache.catalina.core.StandardEngine);
Object engine = engineClass.newInstance();
} catch (Exception ex) {
}
}
will give a : StandardEngine[null]
. note that the full package name is missing and that engineClass is
found.
If anybody can shed any light on this, I'd be very grateful for comment
nick
Re: Security issues with Tomcat 3.2.x
On Wed, 22 Aug 2001 09:41:04 -0500, you wrote: JkMount /*.jsp ajp13 Yes, this solves my problem. But I think this issue should be documented. I remember having read about this command for telling Apache to forward *all* .jsp pages to Tomcat, but I haven't seen any advice for preventing the // source view problem described. Normally people will think that if he/she has his/her jsp's on foo directory it is sufficient with something like JkMount /foo/*.jsp ajp13. The // is tricky... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** [EMAIL PROTECTED] http://pagina.de/romansoft ~~~
Re: Security issues with Tomcat 3.2.x
On Tue, 21 Aug 2001 09:47:33 -0500, you wrote: The problem is that Apache is serving the file and not forwarding the request to Tomcat. Tomcat would *not* return the JSP contents for this URL, it would return a 404 error. Yes, it could be but... I've heard this same problem from another user who is also using Apache 1.3.20. I can't duplicate the problem using Apache 1.3.19 so maybe something changed in the latest version of Apache. Are you using mod_jserv instead of mod_jk? I have another server with similar Apache setup (and same version: 1.3.20) but using mod_jserv (instead of mod_jk). This time the bug couldn't be reproduced. I also noticed that Apache/Tomcat changes URL replacing the \ char by a /. I mean, if I enter http://www.foo.com/\bar/home.jsp; on browser then it is automatically changed to http://www.foo.com//bar/home.jsp; and 404 error is returned. Who is doing such replacement? Apache or Tomcat? Perhaps it could be the trace that confirms who is serving the .jsp source. Some data: This is the mod_jserv machine (apparently not vulnerable): Server version: Apache/1.3.20 (Unix) Server built: Jul 4 2001 19:52:43 Server's Module Magic Number: 19990320:10 Server compiled with -D EAPI -D HAVE_MMAP -D HAVE_SHMGET -D USE_SHMGET_SCOREBOARD -D USE_MMAP_FILES -D USE_SYSVSEM_SERIALIZED_ACCEPT -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D HTTPD_ROOT=/usr/local/apacheJSP -D SUEXEC_BIN=/usr/local/apacheJSP/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/httpd.scoreboard -D DEFAULT_LOCKFILE=logs/httpd.lock -D DEFAULT_XFERLOG=logs/access_log -D DEFAULT_ERRORLOG=logs/error_log -D TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf -D ACCESS_CONFIG_FILE=conf/access.conf -D RESOURCE_CONFIG_FILE=conf/srm.conf This is the mod_jk machine (*vulnerable*): Server version: Apache/1.3.20 (Unix) Server built: Jul 10 2001 18:04:44 Server's Module Magic Number: 19990320:10 Server compiled with -D EAPI -D HAVE_MMAP -D HAVE_SHMGET -D USE_SHMGET_SCOREBOARD -D USE_MMAP_FILES -D USE_SYSVSEM_SERIALIZED_ACCEPT -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D HTTPD_ROOT=/usr/local/apache -D SUEXEC_BIN=/usr/local/apache/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/httpd.scoreboard -D DEFAULT_LOCKFILE=logs/httpd.lock -D DEFAULT_XFERLOG=logs/access_log -D DEFAULT_ERRORLOG=logs/error_log -D TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf -D ACCESS_CONFIG_FILE=conf/access.conf -D RESOURCE_CONFIG_FILE=conf/srm.conf I'd go back to Apache 1.3.19 and see if that fixes the problem. Another solution is to add the following line to your mod_jk.conf file JkMount /bar/* ajp13 This doesn't solve the problem because the \ trick is performed before /bar. Since I'm requesting bar.jsp, it would equally match /bar/*.jsp as well as /bar/*. Any ideas? TIA =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** [EMAIL PROTECTED] http://pagina.de/romansoft ~~~
Re: security and a servlet using core catalina classes
I am sorry, it seems I was not clear enough.
I wrote a servlet in a classic WAR file at an arbitrary location and NOT in the
org.apache.catalina package. The source code I copied in my last message was the
source code of the doGet() method for THIS servlet (outside the catalina package). And
it worked!
I was able to access a method on the Deployer, i.e. I was able to access anything
public in any Container from outside. This is only working by using reflection.
Conclusion: there is a security issue. We don't need the prerequisite to access
Catalina core classes.
Regards,
Fabien
Craig R. McClanahan [EMAIL PROTECTED] writes:
On 9 May 2001, Fabien Le Floc'h wrote:
Ok, this is possible to bypass the security!
Catalina conforms to the behavior in the Servlet 2.3 PFD2
Specification (Section 9.7.2) but does not comply with its
recommended behaviour.
Which recommended behavior are you concerned about? Catalina implements
both of them:
* not allow servlets in the WAR access to the web container's
implementation classes (which would be necessary to accomplish
what you are after here -- Catalina only lets servets installed in
$CATALINA_HOME/servlet have this kind of access).
* the application classloader be implemented so that classes and
resources packaged within the WAR are loaded in preference to
classes and resources residing in container-wide library JARs.
The fact that Catalina implements the second recommendation (which is
different behavior than Tomcat 3.2) means that you can have version X of
a particular package (say, a JDBC driver) available in the
$CATALINA_HOME/lib directory, but still be able to override it by placing
version Y of this driver, with the same package and class names, in your
WEB-INF/lib directory.
Here is the code (not clean, sorry about that) for the doGet method of an regular
servlet:
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
Object theWrapper = (Object) this.getServletConfig();
try {
Method method = theWrapper.getClass().getMethod(getParent, new Class[]
{});
Object theContext = method.invoke(theWrapper, new Object[] {});
method = theContext.getClass().getMethod(getParent, new Class[] {});
Object theDeployer = method.invoke(theContext, new Object[] {});
method = theDeployer.getClass().getMethod(findDeployedApps, new Class[]
{});
Object deployedApps = method.invoke(theDeployer, new Object[] {});
String[] apps = (String[]) deployedApps;
writer.println(detected apps:);
for (int i=0; iapps.length;i++) {
writer.println(apps[i]);
}
} catch (Exception e) {
e.printStackTrace();
writer.println(An exception occured when invoking the method,
+e.getMessage());
}
writer.flush();
writer.close();
Yes, you will need access to Catalina internal structures to make this
work (via reflection or not does not matter). The prerequisites are:
* Your admin servlet must be in package org.apache.catalina (or a
subpackage of this package).
* Your admin servlet must be installed in $CATALINA_HOME/server/classes
or in a JAR file in $CATALINA_HOME/server/lib so that the Catalina
internal class loader can see it.
My project is to build a servlet inspector servlet for Tomcat in order
to have a Dynamo DCC like feature.
You might want to check out the Manager web app that is included already,
to see if it meets some or all of your needs. For example, to list the
webapps that are installed in a Tomcat 4.0 installation, simply execute:
http://localhost:8080/manager/list
To make this work, you must define a user (by default in the
$CATALINA_HOME/conf/tomcat-users.xml file) that has role manager,
because this web application is password protected by default. The
username and password assigned are arbitrary, as long as the authenticated
user is assigned the manager role.
The source code for this servlet
(org.apache.catalina.servlets.ManagerServlet) illustrates how
container-managed servlets can have direct access to Catalina internals
via casting (no reflection is required), because they are loaded by the
same class loader. As long as arbitrary users are prevented from
installing things under $CATALINA_HOME/server, the security of the
system itself is not compromised -- but you can easily create web
applications that have full access to internal server functionality.
(The invoker servlet that processes paths like /servlet/foo, and the
default servlet that serves static resources, are other examples of
container managed servlets that have access to internal Catalina classes
in exactly the same way.)
Regards,
Fabien
Craig
Re: security and a servlet using core catalina classes
On 9 May 2001, Fabien Le Floc'h wrote:
Ok, this is possible to bypass the security!
Catalina conforms to the behavior in the Servlet 2.3 PFD2
Specification (Section 9.7.2) but does not comply with its
recommended behaviour.
Which recommended behavior are you concerned about? Catalina implements
both of them:
* not allow servlets in the WAR access to the web container's
implementation classes (which would be necessary to accomplish
what you are after here -- Catalina only lets servets installed in
$CATALINA_HOME/servlet have this kind of access).
* the application classloader be implemented so that classes and
resources packaged within the WAR are loaded in preference to
classes and resources residing in container-wide library JARs.
The fact that Catalina implements the second recommendation (which is
different behavior than Tomcat 3.2) means that you can have version X of
a particular package (say, a JDBC driver) available in the
$CATALINA_HOME/lib directory, but still be able to override it by placing
version Y of this driver, with the same package and class names, in your
WEB-INF/lib directory.
Here is the code (not clean, sorry about that) for the doGet method of an regular
servlet:
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
Object theWrapper = (Object) this.getServletConfig();
try {
Method method = theWrapper.getClass().getMethod(getParent, new Class[]
{});
Object theContext = method.invoke(theWrapper, new Object[] {});
method = theContext.getClass().getMethod(getParent, new Class[] {});
Object theDeployer = method.invoke(theContext, new Object[] {});
method = theDeployer.getClass().getMethod(findDeployedApps, new Class[]
{});
Object deployedApps = method.invoke(theDeployer, new Object[] {});
String[] apps = (String[]) deployedApps;
writer.println(detected apps:);
for (int i=0; iapps.length;i++) {
writer.println(apps[i]);
}
} catch (Exception e) {
e.printStackTrace();
writer.println(An exception occured when invoking the method,
+e.getMessage());
}
writer.flush();
writer.close();
Yes, you will need access to Catalina internal structures to make this
work (via reflection or not does not matter). The prerequisites are:
* Your admin servlet must be in package org.apache.catalina (or a
subpackage of this package).
* Your admin servlet must be installed in $CATALINA_HOME/server/classes
or in a JAR file in $CATALINA_HOME/server/lib so that the Catalina
internal class loader can see it.
My project is to build a servlet inspector servlet for Tomcat in order
to have a Dynamo DCC like feature.
You might want to check out the Manager web app that is included already,
to see if it meets some or all of your needs. For example, to list the
webapps that are installed in a Tomcat 4.0 installation, simply execute:
http://localhost:8080/manager/list
To make this work, you must define a user (by default in the
$CATALINA_HOME/conf/tomcat-users.xml file) that has role manager,
because this web application is password protected by default. The
username and password assigned are arbitrary, as long as the authenticated
user is assigned the manager role.
The source code for this servlet
(org.apache.catalina.servlets.ManagerServlet) illustrates how
container-managed servlets can have direct access to Catalina internals
via casting (no reflection is required), because they are loaded by the
same class loader. As long as arbitrary users are prevented from
installing things under $CATALINA_HOME/server, the security of the
system itself is not compromised -- but you can easily create web
applications that have full access to internal server functionality.
(The invoker servlet that processes paths like /servlet/foo, and the
default servlet that serves static resources, are other examples of
container managed servlets that have access to internal Catalina classes
in exactly the same way.)
Regards,
Fabien
Craig
Re: security and a servlet using core catalina classes
On Wed, 9 May 2001, Craig R. McClanahan wrote: Catalina only lets servets installed in $CATALINA_HOME/servlet have this kind of access). Oops, that's actually $CATALINA_HOME/server. Craig
RE: [Security Issue] Sessions are visible across multiple clients
Probably partially resolved by the patch I forward previously. From M. Frey La prise de conscience de votre propre ignorance est un grand pas vers la connaissance. -- Benjamin Disraeli -Original Message- From: Amrhein, Thomas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 5:59 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Security Issue] Sessions are visible across multiple clients Hi all, one session can be visible on multiple clients!! THIS IS A BIG SECURITY PROBLEM! Someone opens his webbrowser and has the session of somebody else. So critical data could be viewed without permission. Somebody can act as somebody else. What's wrong with tomcat's session-handling? I wrote a web application which can reproduce this. I'm working with Tomcat 3.3m1 on WinNT4. On 3.2 I have the same problems sometimes with our application but it is not reproducable there. To reproduce this: - put sessiontest.war in %TOMCAT_HOME%/webapps/ - start Tomcat - open browser1 (Netscape 4.7 or IE5) on machine1 (close it before if it's already open) - locate browser1 on http://yourtomcat/sessiontest/index.jsp (a cookie will be set) - browser1: login with name for example 'Testuser1' - browser1: show settings (The name is displayed) - open browser2 on machine2 (close it before if it's already open) - locate browser2 on http://yourtomcat/sessiontest/index.jsp (a cookie will be set) Browser2 now sees the same content like browser1 (logged in as Testuser1). Look for the sourcecode in the .war. All objects are session-bound. Normally you should not be logged in. Remember that you are on different machines! They should have different cookies, different sessions, different usernames. Sometimes but not often, they have the same Session-ID (I can not reproduce this). Bug #723: sessions are not properly recycled Perhaps my issue belongs to this. I've seen different bugs reported but not solved belonging to session-handling. #131,152,183,189,267,429,723,731 Can somebody reproduce this behaviour somewhere else? And can this behaviour also happen in Tomcat 3.2/3.2.1 (I don't know the code)? regards, Thomas PS: I'm new to tomcat-dev-mailinglist (two or three hours) to stay tuned. Perhaps it's already discussed and patched. Please inform me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Security Issue] Sessions are visible across multiple clients
It has more to do with a bug in SimpleSessionStore.java. It recycles the
session on create, so then the instance is re-used for the next new session.
I've patched it via:
*** SimpleSessionStore.java.origMon Feb 26 14:59:53 2001
--- SimpleSessionStore.java Wed Feb 28 09:36:40 2001
***
*** 426,432
if (session == null) {
session = new ServerSession();
session.setManager( this );
- recycled.put( session );
}
// XXX can return MessageBytes !!!
--- 426,431
- Original Message -
From: "GOMEZ Henri" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, February 28, 2001 8:59 AM
Subject: RE: [Security Issue] Sessions are visible across multiple clients
Probably partially resolved by the patch I forward previously.
From M. Frey
La prise de conscience de votre propre ignorance est un grand pas vers la
connaissance.
-- Benjamin Disraeli
-Original Message-
From: Amrhein, Thomas [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 28, 2001 5:59 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Security Issue] Sessions are visible across multiple clients
Hi all,
one session can be visible on multiple clients!!
THIS IS A BIG SECURITY PROBLEM!
Someone opens his webbrowser and has the session of somebody else.
So critical data could be viewed without permission.
Somebody can act as somebody else.
What's wrong with tomcat's session-handling?
I wrote a web application which can reproduce this.
I'm working with Tomcat 3.3m1 on WinNT4.
On 3.2 I have the same problems sometimes with our application
but it is not reproducable there.
To reproduce this:
- put sessiontest.war in %TOMCAT_HOME%/webapps/
- start Tomcat
- open browser1 (Netscape 4.7 or IE5) on machine1 (close it
before if it's
already open)
- locate browser1 on http://yourtomcat/sessiontest/index.jsp
(a cookie will
be set)
- browser1: login with name for example 'Testuser1'
- browser1: show settings (The name is displayed)
- open browser2 on machine2 (close it before if it's already open)
- locate browser2 on http://yourtomcat/sessiontest/index.jsp
(a cookie will
be set)
Browser2 now sees the same content like browser1 (logged in as
Testuser1).
Look for the sourcecode in the .war. All objects are session-bound.
Normally you should not be logged in.
Remember that you are on different machines! They should have different
cookies, different
sessions, different usernames.
Sometimes but not often, they have the same Session-ID (I can
not reproduce
this).
Bug #723: sessions are not properly recycled
Perhaps my issue belongs to this.
I've seen different bugs reported but not solved belonging to
session-handling.
#131,152,183,189,267,429,723,731
Can somebody reproduce this behaviour somewhere else?
And can this behaviour also happen in Tomcat 3.2/3.2.1 (I
don't know the
code)?
regards,
Thomas
PS: I'm new to tomcat-dev-mailinglist (two or three hours) to
stay tuned.
Perhaps it's already discussed and patched. Please inform me.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
If the diff between 3.1.1 and 3.1 is small, yes, they can upgrade to 3.1.1 and not to 3.2. That's what being in production is like. Enough has changed between 3.1 and 3.2 that any application should go through a full QA cycle before being moved to the new platform. Not that I would really expect anything to show up, but it would be irresponsible not to. Forcing people to take new features along with bug fixes is never a good idea. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Monday, December 11, 2000 9:55 PM To: [EMAIL PROTECTED] Subject: Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2 on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. -jon -- Honk if you love peace and quiet. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1 I'll still be for security updates but release a 3.1.1 could make some users thinking the 3.1 tree is still alive. Could be disturbing some days after 3.2 release. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. + 1 I've also fixed ajp13/multiples cookies. Will it be included ?
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
"Craig R. McClanahan" wrote: Over the last three days, a review of published and soon-to-be-published reports of security vulnerabilities in Tomcat has uncovered a series of problems in the 3.1 final release, and a couple of less serious (but still significant) problems in 3.2. Please vote (quickly) on the following two issues: Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1 Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. Very shortly I will have some updated documents for configuring Tomcat to use the Java SecurityManager under various flavors of MS Windows. I would like to get this into the 3.2.1 release. +1 If you can hold off a day so I can get these documents updated Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2 From: Jon Stevens [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? Yes, that is actually the situation. I can tell you that in our application, the changes implied by moving from 3.1 to 3.2 were significant (we use Tomcat in an embedded manner, dynamically incorporating servlets to contexts), mainly because there were implementation differences in the APIs (for Contexts, facades, etc). No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. We cannot 'make people upgrade'. There are organizations that rely on a certain revision of the software. The decision of upgrading or not is not only hinged on the advantages but in the drawbacks (the time to regression-test that the application still functions, the time to spend to verify that the change is 'transparent', etc), therefore, there are going to be users that will not upgrade to 3.2 but will be willing to move to 3.1.1. I would argue that a move from 3.1 to 3.1.1 falls into the category of transparent move, while not being able to say the same of moving from 3.1 to 3.2. Arieh -jon -- Honk if you love peace and quiet. -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
I have to agree with Arieh on this one. Coming from an organization that has a very rigerous change management process I know that it can take upwards of 4 months to release a piece of software, let alone a server upgrade that is not just a security fix. If it adds features above and beyond the current rev then all of the parties with applications or code on that server have to be notified and they have to submit change management requests for testing etc Imagine a coders hell ... and you have change management. I think a 3.1.1 release makes sence but I also think it is important in the release notes that we not only tell them that it is important that they attempt to get on the latest rev of tomcat (3.2.1 in this case) but if we can also make some suggestions on how they can start changing their coding now to prepare for the 4.0 transition. I am not sure if that is easier said then done but it is a suggestions ... Sean - Original Message - From: "Arieh Markel" [EMAIL PROTECTED] I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? Yes, that is actually the situation. I can tell you that in our application, the changes implied by moving from 3.1 to 3.2 were significant (we use Tomcat in an embedded manner, dynamically incorporating servlets to contexts), mainly because there were implementation differences in the APIs (for Contexts, facades, etc). No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. We cannot 'make people upgrade'. There are organizations that rely on a certain revision of the software. The decision of upgrading or not is not only hinged on the advantages but in the drawbacks (the time to regression-test that the application still functions, the time to spend to verify that the change is 'transparent', etc), therefore, there are going to be users that will not upgrade to 3.2 but will be willing to move to 3.1.1. I would argue that a move from 3.1 to 3.1.1 falls into the category of transparent move, while not being able to say the same of moving from 3.1 to 3.2. Arieh -jon -- Honk if you love peace and quiet. -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
[EMAIL PROTECTED] 12/11/00 06:19PM Over the last three days, a review of published and soon-to-be-published reportsof security vulnerabilities in Tomcat has uncovered a series of problems in the3.1 final release, and a couple of less serious (but still significant) problemsin 3.2. Please vote (quickly) on the following two issues:Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems. . . . +1Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problemsplus the patches committed to date.. . . +1 If possible, I would like to see the two patches that I posted (and sent to Craig) for NetWare in the 3.2.1 build. They only affect the native connectors on NetWare, but there are several people inside and outside of Novell that are starting to use Tomcat 3.2. If not, I'll try and keep as many of these as I know about up to date with what I build until the patches are checked in. Either way, security fixes are more important. Craig Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. I was not privi to a few of the original posts regarding this. Is the vulnerability only exposed if one can access the tomcat port directly? So if I blocked all access to say port 9090 (where my tomcat port is) from any foreign machines, then it is safe? Or is the vulnerability exposed even when accessing tomcat via apache port 80? -- Freddie Mendoza [EMAIL PROTECTED]
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. +1. Remy
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
"Craig R. McClanahan" wrote: [...] Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +0. Is removing TC 3.1 from the download pages an alternative? There shouldn't be any reason for anyone to use TC 3.1 now when 3.2 is released. Upgrading to 3.2.1 could be the recommended action for all TC 3.1 users that need to plug the security holes. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. +1 Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Hans Bergsten wrote: "Craig R. McClanahan" wrote: [...] Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +0. Is removing TC 3.1 from the download pages an alternative? There shouldn't be any reason for anyone to use TC 3.1 now when 3.2 is released. Upgrading to 3.2.1 could be the recommended action for all TC 3.1 users that need to plug the security holes. I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. +1 Hans Craig
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
on 12/11/2000 5:19 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Over the last three days, a review of published and soon-to-be-published reports of security vulnerabilities in Tomcat has uncovered a series of problems in the 3.1 final release, and a couple of less serious (but still significant) problems in 3.2. Please vote (quickly) on the following two issues: Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems I have just posted a CVS commit that fixes the security vulnerabilities that I know about, plus a release notes document (src/doc/readme) that describes what was changed. I propose to create and announce an official release that reflects these changes. Note that there are no other functionality or bug fixes changes to 3.1 being proposed, nor (IMHO) are any non-security-related fixes likely to be forthcoming in the future. Therefore, I would propose to include a "strong encouragement" for existing 3.1 users to update to 3.2 in order to benefit from the bug fixes and security enhancements that it includes. I think that we should just ask people to upgrade to 3.2.x Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. +1 I propose that we cut a Tomcat 3.2.1 release that includes these two fixes, plus other bug fixes that have been committed to date. Additional bug fixes that have been proposed but not yet committed can be included in a subsequent 3.2.2 release. +1 PS: Tomcat 4.0-m4 is vulnerable to the first of the two problems listed above for 3.2 -- a fix has been posted, and will be included in the previously announced milestone 5 release that is imminenet. +1 -jon -- Honk if you love peace and quiet.
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. -jon -- Honk if you love peace and quiet.
RE: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1 Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. + 1 Larry
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
On Mon, 11 Dec 2000, Craig R. McClanahan wrote: Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. BTW: I think it should be made clear this is only an issue if you are not using a webserver, like apache, in front of the Container. A properly configured apache renders these vulnerabilites moot. -Nick
