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]
[SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
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. 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. 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. Craig 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.
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
