RE: Tomcat4 denial of service in debian...

[Dan K.]

Yoav/Remy,

Thanks :)

Regards,
Dan

On Thu, 16 Oct 2003, Shapira, Yoav wrote:

>
> Howdy,
>
> >So then if there is a DoS vulnerability in the "normal jakarata tomcat
> >4.0.x distributions", would the developers consider that important
> enough
> >to be looked at/fixed?
>
> Possibly ;)  One would have to prove the vulnerability exists.
>
> Yoav Shapira
>
>
>
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
>
>
> -
> 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: Tomcat4 denial of service in debian...

[Dan K.]

Yoav,

So then if there is a DoS vulnerability in the "normal jakarata tomcat
4.0.x distributions", would the developers consider that important enough
to be looked at/fixed?  I'm just trying to figure out whether the
vulnerability in the debian tomcat would affect the normal jakarta tomcat
versions >= 4.0.4 (i'm using the normal jakarta distributed tomcat 4.0.6).
Upgrading to the 4.1 branch would require more work for us. :(

Regards,
Dan

On Thu, 16 Oct 2003, Shapira, Yoav wrote:

>
> Howdy,
>
> >However, I'd still like to be certain that 4.0.6 is ok... Perhaps I
> should
> >post to the developer's list..?
>
> That won't get you any further.  Contrary to what one might think, most
> if not all tomcat developers lurk on this list.  AFAIK no one uses
> Debian, and at this point unless there's a showstopper we don't care
> that much about the 4.0.x branch.
>
> Yoav Shapira
>
>
>
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
>
>
> -
> 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: Tomcat4 denial of service in debian...

[Dan K.]

Thanks Yoav, as always you're very helpful.

However, I'd still like to be certain that 4.0.6 is ok... Perhaps I should
post to the developer's list..?

Regards,
Dan

On Thu, 16 Oct 2003, Shapira, Yoav wrote:

>
> Howdy,
> I think 4.0.6 is OK.  The 4.1 branch stable releases are OK as well, and
> recommended as they use the Coyote connector by default (which is
> relevant to this security advisory).
>
> Yoav Shapira
> Millennium ChemInformatics
>
>
> >-Original Message-
> >From: Dan K. [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, October 16, 2003 11:37 AM
> >To: Tomcat Users List
> >Subject: Tomcat4 denial of service in debian...
> >
> >
> >Hi,
> >
> >Does anyone know if the version of tomcat4 mentioned in the
> >following advisory applies to 4.0.6?
> >
> >http://www.securityfocus.com/archive/1/341310
> >
> >I get the idea that it only applies to the debian packaged version
> >(4.0.3?)... ??
> >
> >Regards,
> >Dan
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
>
>
> -
> 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]

Tomcat4 denial of service in debian...

[Dan K.]

Hi,

Does anyone know if the version of tomcat4 mentioned in the
following advisory applies to 4.0.6?

http://www.securityfocus.com/archive/1/341310

I get the idea that it only applies to the debian packaged version
(4.0.3?)... ??

Regards,
Dan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk fail-over setup w/ apache 1.3, tomcat 4.0.x, debian linux

[Dan K.]

FYI..

There is a doc on how to setup:

"Apache 1.3, Tomcat 4.0.x, mod_jk, fail-over/back setup
on Linux (Debian3.0-woody)"

at

http://www.yorku.ca/dkha/tomcat/docs/apache-tomcat-modjk.htm

Hopefully it will be useful to someone.

Regards,
Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

weird mod_jk log messages

[Dan K.]

Hello everyone,

I've looked through the mail archives for this mailing list and haven't
found an answer to the weird mod_jk log message I get.

So to end it once and for all, can any one please tell me why the
following (see log below) is showing up in my mod_jk.log file?  Are you
guys getting this and ignoring it, or do you set the log level to "emerg"
so they don't show up (they show up using JkLogLevel "error")?
Yet, my apps seems to work...?

I'm using Linux (Debian 3.0), mod_jk 1.2.2 binary for Linux i386
downloaded from the tomcat-connectors project, Tomcat 4.0.4 (I know, I
haven't had the chance to upgrade to 4.0.6 or 4.1.x yet but from the logs
posted by others I don't think it's specific to TC 4.0.4).

Here's a snippet of the mod_jk.log output:

[Tue Mar 18 21:51:56 2003]  [jk_ajp_common.c (681)]: ERROR: can't receive
the response message from tomcat, network problems or tomcat is down.
[Tue Mar 18 21:51:56 2003]  [jk_ajp_common.c (1050)]: Error reading reply
from tomcat. Tomcat is down or network problems.
[Tue Mar 18 21:51:56 2003]  [jk_ajp_common.c (1187)]: ERROR: Receiving
from tomcat failed, recoverable operation. err=0

Many thanks in advance.

Regards,
Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Dan K.]

I'm referring to Tomcat v4.0.4 with Turbine v2.1 on both Windows XP
and Linux platforms, and yes it does suffer from the vulnerability.

I've not tried the fixed versions 4.0.5 or 4.1.12 yet.

Regards,
Dan

On 25 Sep 2002, Rob Reed wrote:

> please let me know if you are still experiencing this. It looks correct
> to me right now.
>
> Thanks,
> Rob Reed
> Isomedia.com
>
> On Wed, 2002-09-25 at 14:28, Dan K. wrote:
> >
> > Hi.  I've just confirmed that Velocity (at least in Turbine v2.1)
> > suffers from this problem.
> >
> > Regards,
> > Dan
> >
> > On Wed, 25 Sep 2002, Rossen Raykov wrote:
> >
> > > The servlets are not vulnerable since their code is under WEB-INF and is
> > > successfully protected from downloads.
> > > All other interpreted application stuff, outside of WEB-INF, like JSP are
> > > vulnerable since they can be downloaded as regular files but not be
> > > processed by the corresponding engine.
> > > That's why I believe Velocity should suffer from this bug in the same way
> > > JSP is.
> > > I didn't test Velocity but there is not any reason that it will be resistant
> > > to this exposure.
> > >
> > > Regards,
> > > Rossen Raykov
> > >
> > > > -Original Message-
> > > > From: Kent Perrier [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, September 24, 2002 6:59 PM
> > > > To: Tomcat Users List
> > > > Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source
> > > > disclosurevulnerability
> > > >
> > > >
> > > > On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote:
> > > > > OK, thanks. (The BugTraq search engine wasn't working when I checked
> > > > > there.)
> > > > >
> > > > > So it sounds pretty much like what I thought it was. I still don't
> > > > > understand why Velocity wouldn't be vulnerable to this exploit.
> > > >
> > > > It sounds to me like it should be.  From the bugtraq post,
> > > > all servlets
> > > > and JSPs that run in a Tomcat instance are vulnerable.  Since Velocity
> > > > runs under Tomcat, logically, it is vulnerable.  All other claims are
> > > > illogical.
> > > >
> > > > Kent
> > > >
> > > > --
> > > > 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]>
> >
>
>
>
> --
> 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 disclosurevulnerability

[Dan K.]

Hi.  I've just confirmed that Velocity (at least in Turbine v2.1)
suffers from this problem.

Regards,
Dan

On Wed, 25 Sep 2002, Rossen Raykov wrote:

> The servlets are not vulnerable since their code is under WEB-INF and is
> successfully protected from downloads.
> All other interpreted application stuff, outside of WEB-INF, like JSP are
> vulnerable since they can be downloaded as regular files but not be
> processed by the corresponding engine.
> That's why I believe Velocity should suffer from this bug in the same way
> JSP is.
> I didn't test Velocity but there is not any reason that it will be resistant
> to this exposure.
>
> Regards,
> Rossen Raykov
>
> > -Original Message-
> > From: Kent Perrier [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, September 24, 2002 6:59 PM
> > To: Tomcat Users List
> > Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source
> > disclosurevulnerability
> >
> >
> > On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote:
> > > OK, thanks. (The BugTraq search engine wasn't working when I checked
> > > there.)
> > >
> > > So it sounds pretty much like what I thought it was. I still don't
> > > understand why Velocity wouldn't be vulnerable to this exploit.
> >
> > It sounds to me like it should be.  From the bugtraq post,
> > all servlets
> > and JSPs that run in a Tomcat instance are vulnerable.  Since Velocity
> > runs under Tomcat, logically, it is vulnerable.  All other claims are
> > illogical.
> >
> > Kent
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

wp-02-0008: Apache Tomcat Cross Site Scripting

[Dan K.]

Hi,

Regarding the recent advisory from Westpoint Security:

-
Westpoint Security Advisory

Title:Apache Tomcat Cross Site Scripting
Risk Rating:  Low
Software: Apache Tomcat v4.0.3
Platforms:WinNT, Win2k, Linux
Vendor URL:   jakarta.apache.org
Author:   Matt Moore <[EMAIL PROTECTED]>
Date: 10th July 2002
Advisory ID#: wp-02-0008

Overview:
=
Apache Tomcat is the servlet container that is used in the official
Reference
Implementation for the Java Servlet and JavaServer Pages technologies.

Tomcat has a couple of Cross Site Scripting vulnerabilities.



Patch Information:
==

Upgrading to v4.1.3 beta resolves the DOS device name XSS issue.

The workaround for the other XSS issues described above is as follows:

The "invoker" servlet (mapped to /servlet/), which executes anonymous
servlet
classes that have not been defined in a web.xml file should be unmapped.

The entry for this can be found in the /tomcat-install-dir/conf/web.xml
file.
-

What does one need to do exactly regarding the work-around for 4.0.x
versions of Tomcat?  Unmapping the "invoker" servlet for /servlet/ seems
to disable my webapps!  Or am I misinterpreting this?
TIA.

Regards,
Dan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

context manager app in server.xml

[Dan K.]

Hi,

Does anyone know what the "privileged" attribute mean for a 
entry for the manager app in server.xml?



Thanks,
Dan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Conncurency issue with tomcat???

[Dan K.]

Hi Raj,

Which jvm are you using?  I remember sun jvm 1.3.0 had an issue with
HttpUrlConnection something I worked on.  Upgrading to the latested jvm
1.3.1_whatever solved it...

Regards,
Dan

On Tue, 21 May 2002, Ghorpade, Rajendra wrote:

> Hi Remy,Peter
>
> After some research I found out that there were no more concurrent session
> problems and the same request processed twice problem when I changed my
> simulator(test program) to use HttpClient API. There could be the a bug in
> implementaion of java.net.HttpUrlConenction.
> I tried HttpUrlConnection with the Coyote connector and I got the concurrent
> session problem and the same request being processed twice problem.
>
> When I used the API from HttpClient for connection I go no concurrent issues
> and the test run realibaly with 90 concurrent users.
>
> Thanx for ur valuable comment on this subject...
>
> Raj
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LoadModule webapp_module modules/mod_webapp.so

[Dan K.]

Also, make sure you have a "ServerName" directive in your httpd.conf if
you don't have it.

Regards,
Dan

On Wed, 24 Apr 2002, Simon Stewart wrote:

> The only other thing that springs to mind is to use a path without
> spaces in, and perhaps to double up your back slashes. Try one, then
> the other, then both. This is something of a last resort, though.
>
> On Wed, Apr 24, 2002 at 11:10:50PM +0800, yilmaz wrote:
> > Hi Simon,
> > I tried apache -t istead (i saw it from someone else's posting) and got:
> > apache: could not open document config file D:/Program
> > Files/E~1/Apache2/conf/httpd.conf
> > error.
> > As you said i changed modules/mod_webapps.so to
> > modules\mod_webapps.so, but still the same frustrating message :(
> > what do you think the problem can be?
> > thanks :)
> > - Original Message -
> > From: "Simon Stewart" <[EMAIL PROTECTED]>
> > To: "Tomcat Users List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, April 24, 2002 10:28 PM
> > Subject: Re: LoadModule webapp_module modules/mod_webapp.so
> >
> >
> > > apachectl configtest ultimately runs "httpd -t", so you could try
> > > "httpd.exe -t" on win32. You might also try reversing the direction of
> > > the file seperator in Windows:
> > >
> > > LoadModule webapp_module modules\mod_webapp.so
> > >
> > > I'm never tried Apache on Win32, but this should help.
> > >
> > > On Wed, Apr 24, 2002 at 09:51:57PM +0800, yilmaz wrote:
> > > > Hi Simon,
> > > > unfortunately i don't know how to do "apachectl configtest".
> > > > from command window i tried that , but didn't work.
> > > > >From apache monitor, when i try to start the server, it throws
> > > > "the requested operation has failed" error, nothing else.
> > > > My httpd.config is okey,  except when i add
> > > > "LoadModule webapp_module modules/mod_webapp.so"
> > > > into the httpd.config file (as it is instructed) , and restart the
> > apache,
> > > > it can't start. Obviously the problem is with the above line of code.
> > > > Any suggestions ?
> > > > Thanks :)
>
> Cheers,
>
> Simon
>
> --
> What happens if a big asteroid hits the Earth?  Judging from realistic
> simulations involving a sledge hammer and a common laboratory frog, we
> can assume it will be pretty bad. - Dave Barry
>
> --
> To unsubscribe:   
> For additional commands: 
> Troubles with the list: 
>


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Which Apache-To-Tomcat Connector

[Dan K.]

Hi,

I thought mod_webapp was suppose to be the successor to mod_jk in tomcat
4.x, and mod_jk only existed for backwards compatibility for tomcat 3.x.
Don't know about mod_jk2 though...

Regards,
Dan

On Wed, 24 Apr 2002, Michael Delamere wrote:

> Although I don´t have the answer, it´s a VERY interesting question.  As you
> said, it appeared that mod_webapp would eventually replace mod_jk which has
> been said to become deprectated at some stage (correct me if I got the
> information wrong).
>
> So why is there a new version of mod_jk?
>
> Unfortunately after visiting the jakarta site I´m none the wiser :-).
>
> bye Michael Delamere
>
>
>
> - Original Message -
> From: "Simon Stewart" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Wednesday, April 24, 2002 2:23 PM
> Subject: Re: Which Apache-To-Tomcat Connector
>
>
> > On Wed, Apr 24, 2002 at 08:04:17AM -0400, Anthony W. Marino wrote:
> > > > On Tue, Apr 23, 2002 at 07:02:38PM -0400, Anthony W. Marino wrote:
> > > > > Any reason for using AJP14 over AJP13?
> > > > > And what about mod_webapp?
> > > >
> > > > I take it that this is mod_jk and mod_jk2? IME, mod_jk and Apache 2
> > > > don't get along well at all[1]. The impression that I've gleaned from
> > > > reading past postings to this list is that mod_webapp is meant to
> > > > supercede mod_jk and is the preferred way of connecting Apache and
> > > > Tomcat.
> > > >
> > >
> > > If mod_webapp is the next generation then why jk2?
> >
> > That question can be read in two ways: "Why did I start off using
> > jk2?" and "why is there a jk2 project, then?"
> >
> > To answer the first question: because at the time, I hadn't done much
> > reading around the subject, and mod_jk was what the other admins that
> > I spoke to were using, albeit with apache 1.3.x
> >
> > The answer to the second interpretation is probably the same :) Also,
> > jk offers some features that webapp doesn't, which may be an incentive
> > for people to want to try and make it work with apache 2.
> >
> > > Is warp in the coyote connectors the mod_webapp that should be used???
> >
> > Good question. The connector that makes use of it is mod_webapp, and
> > this is part of the jakarta-tomcat-connectors project, if that helps?
> > Getting a listing of the classes that are contained in the
> > "tomcat-*.jar" files doesn't indicate anything called "*warp*", but
> > that could just be because it's the protocol name
> >
> > Cheers,
> >
> > Simon
> >
> > --
> > Hanlon's Razor:
> > Never attribute to malice that which is adequately explained
> > by stupidity.
> >
> > --
> > To unsubscribe:   
> > For additional commands: 
> > Troubles with the list: 
> >
>
>
> --
> To unsubscribe:   
> For additional commands: 
> Troubles with the list: 
>


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: SingleSignOn Or Security Constraint ?

[Dan K.]

Hi,

Correct me if I'm not thinking straight but doesn't the Single Sign-on and
Security Constraint in the web.xml file do different things?  The single
sign-on allows the user to remained logged in while traversing different
webapps and the Security Constraint determines who has access to the
webapp.

Regards,
Dan

On Thu, 18 Apr 2002, Renato Romano wrote:

> I just configured Single Sign on on my Tomcat4 server, and was just
> wondering what's the best way to chose, when I have to add a new service
> to my site, if just adding  a security constraint, in my main Context,
> or configuring and using single signon, for achieving the same result!
>
> It seems to me that using singlesignon has the following advantages:
> 1) I create a service as a standalone application, that can then be
> deployed elsewhere;
> 2) I don't have to restart Tomcat in order to deploy/restart the new
> service, or making it temporary unavailable, thanks to the manager
> application;
> 3) I can continue sharing java classes, by putting them in the "common"
> dir;
> 4) In my situation, obviously, a centralized database of users and roles
> is ok; different context on tomcat, in my environment, should only
> appear as different "services" or "roles", just similar to defining new
> security constraints.
>
> I have not investigated too much on this topic, so the question is: is
> there something I don't see that can cause problems using single signon
> in this way ? Has someone already had such a doubt and how he/she solved
> it ?
>
> Thanks
> Renato
>
> 
> Renato Romano
> Sistemi e Telematica S.p.A.
> Calata Grazie - Vial Al Molo Giano
> 16127 - GENOVA
>
> e-mail: [EMAIL PROTECTED]
> Tel.:   010 2712603
> _
>
>
> --
> To unsubscribe:   
> For additional commands: 
> Troubles with the list: 
>


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

tomcat 4.0.x auth tied to Turbine?

[Dan K.]

Hi everyone,

I was just wondering if there were any brave souls who has played with
Tomcat 4's authentication (Authenticators, Realms) and integrating it
with Turbine (I'm using 2.1 but any version is ok for discussion), and of
course with a datasource for the usernames/password?   If so, perhaps we
can share ideas on the best practices on doing this or anything similar?

Regards,
Dan


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

in web.xml

[Dan K.]

Hi,

Does anyone on the list know where the  element is verified
in the tomcat 4.0.x source?  For example I have the following web.xml
snippet:



Protected Web Application
/servlet/*



user_role



The above protects the url /servlet/* works but but I would
like to change it so that it will also work for
/servlet/protected* which doesn't seem to work.  Anyone got
ideas?  Is there anything security problem in allowing this?

Thanks in advance.

Regards,
Dan


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: Question on reloading web-applications.

[Dan K.]

Hi,

IMHO, you wouldn't want to set the reloadable parameter to true in a
production environment as it needlessly adds processing overhead to check
if things have changed.  And at least for me, I've noticed in setting it
to true, after 10-15 reloads of a webapp tomcat would hang on subsequent
requests... Has anyone else encountered this on Windows (NT/2k) by the
way?

Regards,
Dan

On Wed, 27 Mar 2002, Fabian Sommer wrote:

> Hi Tarun,
>
> >One way would be provide every user a way to reload their web-application only, 
>without granting
>
> >access to the manager application (and thus without bothering the sys-admin). Or is 
>there a parameter
>
> >in Tomcat that checks whether the class files have changes every once in a 
>time-interval
>
> I thought exactly this is what happens if the reloadable parameter is set to 
>"true"...
>
> If i'm wrong please let me know.
>
> Fabian
>
>
>
>
> --
> To unsubscribe:   
> For additional commands: 
> Troubles with the list: 
>


--
To unsubscribe:   
For additional commands: 
Troubles with the list: