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. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
"Craig R. McClanahan" wrote: > > Glenn Nielsen wrote: > > > 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 > > > > I would be really uncomfortable holding off security related fixes for "feature" > improvements (or even bug fixes), when we can roll a 3.2.2 release as soon as the > changes are committed and tested. Keep in mind that we're bypassing the usual "beta > test" period if we release 3.2.1 ASAP, so adding lots of things creates some measure > of risk. > Thats fine, it can wait. +1 on ASAP release of 3.2.1 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
> > > 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
Glenn Nielsen wrote: > 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 > I would be really uncomfortable holding off security related fixes for "feature" improvements (or even bug fixes), when we can roll a 3.2.2 release as soon as the changes are committed and tested. Keep in mind that we're bypassing the usual "beta test" period if we release 3.2.1 ASAP, so adding lots of things creates some measure of risk. > Regards, > > Glenn > Craig PS: Thanks to Arieh for catching my stupid typo in the fixes for META-INF and WEB-INF checking ... I will make sure those are repaired before cutting the real releases.
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Nick Bauman wrote: > 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. > I suppose that depends on the definition of "properly configured". The standard config files we generate for Apache would not protect all of the cases, although it would catch some of them. > > -Nick Craig
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 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.>. . . +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
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
> 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
"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
I think that a 3.1.1 should also be updated and release. There are those of us out hear using 3.1 that cannot immediately upgrade to 3.2. In particular, I cannot upgrade right now because of my applications use the old xml parser for my applications (xml.jar) and 3.2 includes the new jax parser. Because of the class loading order, I cannot use the old xml parser privately in my application. Just my $.02 worth. __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
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 ?
[PATCH] Jakarta site release page (was: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2)
Hans Bergsten typed the following on 17:39 11/12/2000 -0800 >+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. This might be a good time to point out that the download page for source code, http://jakarta.apache.org/site/sourceindex.html, has reverted to listing Tomcat 3.1 as "the latest release quality Tomcat build", and doesn't have a link to the 3.2 final release. It looks like a change to the file yesterday overwrote the new info. Here's a patch, although it's probably easier to change by hand. The binaries page seems ok. @@ -178,8 +178,8 @@ -Tomcat -3.1 is the latest release quality Tomcat build. +Tomcat +3.2 is the latest release quality Tomcat build. Ant 1.2 is the latest release of the Ant Subproject. @@ -189,7 +189,6 @@ -Tomcat 3.2 beta 8 Tomcat 4.0 milestone 3 --- bitBull makes the Internet bite: http://www.bitBull.com/demos/
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
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 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
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
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
"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
> 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
[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.
