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

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

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 - T

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

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

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 wor

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 is

Re: Fwd: Re: security hole on windows tomcat?

n 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: [E

Re: Fwd: Re: security hole on windows tomcat?

ct 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]

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

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 n

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

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

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

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 prote

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) {

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 (se

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

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 program

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, >

Re: security

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 Stri

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 >> doPrivilege

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 -

Re: [Security Audit] CoyoteRequest.doGetSession

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.

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

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 disc

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 currentl

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 wil

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-Franc

Re: Velocity (was RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability)

jan 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 > > B

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 th

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 ma

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 ..

[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

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, sen

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 = "

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$oo

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 discu

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.

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 "greatne

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 canno

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 cour

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. Sel

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 serv

RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability

: 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 acco

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

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

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 c

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 s

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. Tha

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:

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 PROTECTE

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,

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: For additional commands, e-mail:

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 al

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"

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] AT&T IP Network Configuration & Provisioning Development -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 7:59 AM To: Tomcat De

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

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 re

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 Relea

Re: security

Please ask this kind of question on the TOMCAT-USER list. See 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 (C

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 p

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 "//

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 u

RE: Security issues with Tomcat 3.2.x

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. I've heard this same problem from another user who is also using Apache 1.3.20. I can't duplicate the problem using Apac

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

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 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

Re: security and a servlet using core catalina classes

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. Here is the code (not clean, sorry about that) for the doGet method of an regular servlet: respo

Re: security and a servlet using core catalina classes

On 9 May 2001, Fabien Le Floc'h wrote: > Thanks for your answer, > > I decided to put my servlet in the catalina hierarchy (on my personal > computer). When it will be more advanced, I could even propose it as a > contribution to catalina. > Any hints on what it actually does? > But I think

Re: [Security Issue] Sessions are visible across multiple clients

OMEZ 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.

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

RE: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2

eally 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] Subjec

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 s

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

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

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 inf

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.

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

Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2

ft-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

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

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.

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

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

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

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 s

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. Upgr

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 recom

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