You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Larry Isaacs <La...@sas.com> on 2003/01/26 05:30:13 UTC
[ANN] Security update: Apache Tomcat 3.3.1a released
Tomcat 3.3.1a has been released to address the following two
vulnerabilities found in Tomcat 3.3.1 and earlier. This
includes Tomcat 3.2.4 and earlier.
Tomcat 4.0.4, 4.0.6, 4.1.12, 4.1.18, and 4.1.19 have been
checked and do not have these vulnerabilities.
Vulnerability where, when used with JDK 1.3.1 or earlier, a
maliciously crafted request could return a directory listing
even when an index.html, index.jsp, or other welcome file is
present. File contents can be returned as well. In the case
of Tomcat 3.2.4 and earlier, contents of files under WEB-INF
could be accessed. If you are using Tomcat 3.3.1 or earlier
with JDK 1.3.1 or earlier, you should either upgrade to JDK 1.4
or later, or upgrade your Tomcat installation to Tomcat 3.3.1a
or a current release of Tomcat 4.
Vulnerability where a malicious web application could read the
contents of some files outside the web application via its web.xml
file in spite of the presence of a security manager. The content
of files that can be read as part of an XML document would be
accessible. If you are running Tomcat 3.3.1 or earlier with a
security manager, and are serving web applications whose web.xml
content is not known to be safe, you should upgrade your Tomcat
installation to 3.3.1a or a current release of Tomcat 4.
You may download Tomcat 3.3.1a binaries and updated jars from:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/
Other Tomcat downloads may be obtained from:
http://jakarta.apache.org/site/binindex.cgi
These vulnerabilities have been fixed in the current Tomcat 3.3.2-dev
files found at:
http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/
Larry
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.20] Tagging soon ?
Posted by Glenn Nielsen <gl...@mail.more.net>.
I was planning on doing some research and testing of custom tag pooling options
(as we discussed last week) this week. It would be nice if the results from
that could get into th 4.1.20 release. Could be a nice performance improvement
for Jasper2.
Regards,
Glenn
Remy Maucherat wrote:
> I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as
> I think fixing the issue is important) tag a new 4.1.20 milestone within
> a few days.
>
> Comments ?
>
> Remy
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.20] Tagging soon ?
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
> We should waiit for 4.1.20....The last 3 versions were broken, and we
> should test it extensively. Unfortunatly, I cannot test it tonigh and
> tomorrow (but latter this the week). We should wait based on experience :-)
Indeed, experience shows we have to be careful with new Xerces releases ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.20] Tagging soon ?
Posted by Jeanfrancois Arcand <jf...@apache.org>.
We should waiit for 4.1.20....The last 3 versions were broken, and we
should test it extensively. Unfortunatly, I cannot test it tonigh and
tomorrow (but latter this the week). We should wait based on experience :-)
-- Jeanfrancois
Glenn Nielsen wrote:
> Xerces 2.3 was just released and claims it fixes the bug we saw with
> Tomcat.
> Perhaps we should test and verify this so we can use it for the
> distributions.
>
> Glenn
>
> Remy Maucherat wrote:
>
>> I plan to port the changes made to JSPC in the Tomcat 5 branch, and
>> (as I think fixing the issue is important) tag a new 4.1.20 milestone
>> within a few days.
>>
>> Comments ?
>>
>> Remy
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.20] Tagging soon ?
Posted by Glenn Nielsen <gl...@mail.more.net>.
Xerces 2.3 was just released and claims it fixes the bug we saw with Tomcat.
Perhaps we should test and verify this so we can use it for the distributions.
Glenn
Remy Maucherat wrote:
> I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as
> I think fixing the issue is important) tag a new 4.1.20 milestone within
> a few days.
>
> Comments ?
>
> Remy
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.20] Tagging soon ?
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Remy Maucherat wrote:
> I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as
> I think fixing the issue is important) tag a new 4.1.20 milestone within
> a few days.
>
> Comments ?
That would be great, but can you please apply the TagLibraryInfoImpl
patch from bug #14302 before you so? Without it, JspC fails for JSP
pages that use tag libraries with the TLD packaged in the JAR file.
This is the same problem as described by bugs #13212 and #14537.
Hans
--
Hans Bergsten <ha...@gefionsoftware.com>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at <http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[4.1.20] Tagging soon ?
Posted by Remy Maucherat <re...@apache.org>.
I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as
I think fixing the issue is important) tag a new 4.1.20 milestone within
a few days.
Comments ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Speaking of which, I'm missing a registration for the hosts (I don't
> know if it's defined in JSR 77).
> Could we add some custom attributes on the object name for wrapper
> (giving the mapping), as well as the host registration, and still comply
> with the spec (I'd say yes, but ...) ?
Sure. JSR77 is very thin - way too thin.
It doesn't forbid container-specific objects - but leves the naming open.
The only issue - we need to get rid of the Listeners and move the JMX
registration in the core objects.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
> If the question is about using JMX1.2 - it was alredy proposed, and it
> seems nobody objected ( but nobody did it either ). If you want to do
> that - all you need is update the mbean descriptors, and change all the
> arrays to use the JNI names ( [Ljava.lang.String; instead of
> java.lang.String[] ). And of course - fix download to get jmxri instead
> of mx4j.
>
> When MX4J implements 1.2, we'll switch back.
> I'm using JMXRI1.2 - and so far it works very nice.
>
> Regarding the registration listener: there are 2 issues you need to
> be carefull. First, it would be good if the code is independent of
> the load order - i.e. listen for notifications but also do a query for
> the existing objects. You can do that using JMX query, or by
> using the attributes. After you take care of the existing mappings,
> you can start listening for registration - you can do both with plain
> JMX1.1.
Speaking of which, I'm missing a registration for the hosts (I don't
know if it's defined in JSR 77).
Could we add some custom attributes on the object name for wrapper
(giving the mapping), as well as the host registration, and still comply
with the spec (I'd say yes, but ...) ?
Thanks,
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> If the question is about using JMX1.2 - it was alredy proposed, and it
>> seems nobody objected ( but nobody did it either ). If you want to do
>> that - all you need is update the mbean descriptors, and change all the
>> arrays to use the JNI names ( [Ljava.lang.String; instead of
>> java.lang.String[] ). And of course - fix download to get jmxri instead
>> of mx4j.
>
> BTW, would it be possible to add a feature in the modeler to autodetec
> the JMX version, and do that transparently ?
The big problem with JMX1.1 is the lack of (declarative) security. That
makes it history - the only reason to support it is the lack of 1.2 support
in the current mx4j.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> If the question is about using JMX1.2 - it was alredy proposed, and it
> seems nobody objected ( but nobody did it either ). If you want to do
> that - all you need is update the mbean descriptors, and change all the
> arrays to use the JNI names ( [Ljava.lang.String; instead of
> java.lang.String[] ). And of course - fix download to get jmxri instead
> of mx4j.
BTW, would it be possible to add a feature in the modeler to autodetec
the JMX version, and do that transparently ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>
>>> BTW - I assume you read the discussion on authorization - the problem
>>> is the same ( mapping requests URIs to constraints ), it would be good
>>> if we can reuse some code.
>>
>>
>> The mapping code is generic. I was thinking about having the mapper do
>> the constraint mappings (as it's the same operation) also.
>
> Oops, I just remembered the mapping rules are not the same (for the
> constraints, it's the first match according to the order defined in
> web.xml).
Yes, don't you love the spec :-) ?
It'll be very fun to watch JSR115 and the Policy - since that's a best
match too ( like all web servers in the world ). Will they break the servlet
spec or the java security spec ? Or both ( and invent their own rules ) ?
Anyway - people who use web servers for authentication are usually aware
and don't mix server auth with servlet auth ( or so I hope... - otherwise
we would have had far more security reports ). Hopefully the Policy based
authorization will be adopted - and the broken servlet authorization
deprecated...
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
>> BTW - I assume you read the discussion on authorization - the problem
>> is the same ( mapping requests URIs to constraints ), it would be good if
>> we can reuse some code.
>
>
> The mapping code is generic. I was thinking about having the mapper do
> the constraint mappings (as it's the same operation) also.
Oops, I just remembered the mapping rules are not the same (for the
constraints, it's the first match according to the order defined in
web.xml).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Costin Manolache wrote:
>>
>>>Remy Maucherat wrote:
>>
>>>Cast the notification to MBeanServerNotification :-)
>>
>>Ok, it sort of works now.
>>
>>The remaining problems:
>>- some attributes need to send JMX notifications (welcome files,
>>mappings, etc) so the mapper can be updated
>>- the Host handling is not dynamic
>>- some operations need also be propagated (removal of a component)
>
>
> What if we simplify this by exposing the mappings, welcome files, etc
> as JMX attributes of context ?
That sounds doable.
> Of course, we won't save the web.xml if someone adds a mapping ( yet :-),
> but you'll only need to listen for context add/remove notifications.
Well, the MBean is never unregistered at the moment, so it's quite
limited ;-)
> And the jmx console would provide more usefull informations.
>
> The methods and info is already there - we just need to expose them.
>
> BTW - I assume you read the discussion on authorization - the problem
> is the same ( mapping requests URIs to constraints ), it would be good if
> we can reuse some code.
The mapping code is generic. I was thinking about having the mapper do
the constraint mappings (as it's the same operation) also.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>
>> Cast the notification to MBeanServerNotification :-)
>
> Ok, it sort of works now.
>
> The remaining problems:
> - some attributes need to send JMX notifications (welcome files,
> mappings, etc) so the mapper can be updated
> - the Host handling is not dynamic
> - some operations need also be propagated (removal of a component)
What if we simplify this by exposing the mappings, welcome files, etc
as JMX attributes of context ?
Of course, we won't save the web.xml if someone adds a mapping ( yet :-),
but you'll only need to listen for context add/remove notifications.
And the jmx console would provide more usefull informations.
The methods and info is already there - we just need to expose them.
BTW - I assume you read the discussion on authorization - the problem
is the same ( mapping requests URIs to constraints ), it would be good if
we can reuse some code.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
> Cast the notification to MBeanServerNotification :-)
Ok, it sort of works now.
The remaining problems:
- some attributes need to send JMX notifications (welcome files,
mappings, etc) so the mapper can be updated
- the Host handling is not dynamic
- some operations need also be propagated (removal of a component)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>>The mapper has a currently unused dependency on JNDI, and I plan to put
>>>it in the org.apache.tomcat.util.http.mapper package.
>>
>>
>> JNDI deps are fine - dependencies on org.apache.naming are not very good
>> ( since tomcat can be used in an app that uses a different naming impl ).
>
> Well, I'm still unsure about physical welcome files. On the plus side,
> it would be considerably faster to do that in the mapper.
>
>>>How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
>>>obvious, but I think I missed it in 1.1. The static queries are of
>>>course similar.
>>
>>
>> It's the same - register a listener on the MBeanServerDelegate.
>
> I tried that, and get a lot of nice notifications about registration,
> but how do I get the ObjectName of the MBean which caused the
> notification (the source of the Notification is the server delegate,
> which doesn't help). ?
Cast the notification to MBeanServerNotification :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>The mapper has a currently unused dependency on JNDI, and I plan to put
>>it in the org.apache.tomcat.util.http.mapper package.
>
>
> JNDI deps are fine - dependencies on org.apache.naming are not very good
> ( since tomcat can be used in an app that uses a different naming impl ).
Well, I'm still unsure about physical welcome files. On the plus side,
it would be considerably faster to do that in the mapper.
>>How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
>>obvious, but I think I missed it in 1.1. The static queries are of
>>course similar.
>
>
> It's the same - register a listener on the MBeanServerDelegate.
I tried that, and get a lot of nice notifications about registration,
but how do I get the ObjectName of the MBean which caused the
notification (the source of the Notification is the server delegate,
which doesn't help). ?
Help :-P
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> The mapper has a currently unused dependency on JNDI, and I plan to put
> it in the org.apache.tomcat.util.http.mapper package.
JNDI deps are fine - dependencies on org.apache.naming are not very good
( since tomcat can be used in an app that uses a different naming impl ).
> How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
> obvious, but I think I missed it in 1.1. The static queries are of
> course similar.
It's the same - register a listener on the MBeanServerDelegate.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
> If the question is about using JMX1.2 - it was alredy proposed, and it
> seems nobody objected ( but nobody did it either ). If you want to do
> that - all you need is update the mbean descriptors, and change all the
> arrays to use the JNI names ( [Ljava.lang.String; instead of
> java.lang.String[] ). And of course - fix download to get jmxri instead
> of mx4j.
>
> When MX4J implements 1.2, we'll switch back.
> I'm using JMXRI1.2 - and so far it works very nice.
Ok.
The new mapper works with my simple test cases and uses some proven (but
basic) sorting algorithms. It appears to be fast, although the algorithm
cost is greater than using a hashtable or a tree. Anyway, it should be a
lot faster than the old mapper (aahhh, zero garbage mapping :-D ), but I
have to wait until I've integrated it with Catalina to know how much.
The mapper has a currently unused dependency on JNDI, and I plan to put
it in the org.apache.tomcat.util.http.mapper package.
I'll use the new fields it introduces to optimize whatever in the
pipeline was not good:
- Checks for /WEB-INF and /META-INF
- B2C conversion for the URI; the encoding will be configurable with an
attribute on the connector (people have been asking for it for some
reason, instead of using UTF-8 :-( ), and will feature a Nasty Cast (TM)
mode for "ISO-8859-1"
- (later) Request dispatcher mapping; I think request dispatching speed
is very important as it is (ab)used by popular frameworks like Struts
> Regarding the registration listener: there are 2 issues you need to
> be carefull. First, it would be good if the code is independent of
> the load order - i.e. listen for notifications but also do a query for
> the existing objects. You can do that using JMX query, or by
> using the attributes. After you take care of the existing mappings,
> you can start listening for registration - you can do both with plain
> JMX1.1.
How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
obvious, but I think I missed it in 1.1. The static queries are of
course similar.
> I don't know if all the components are registered - we do have the Context
> and Servlet, but you'll need to make sure the Context mbean is exposing the
> mappings. Unfortunately JSR77 ( or other standards I know ) do not define
> any standard attribute that a "WebModule" mbean would use to expose
> supported mappings - so the code will remain dependent of catalina, but
> with less cupling.
That's a problem. Too bad ...
> BTW, I am now able to create Context mbeans and have them registered
> automatically - and I'll try to get the same working for Valves, Connectors
> and JkHandlers. If this is used with an mbean server that supports
> reloading ( like jboss.mx ) - we'll be able to replace modules without
> restarting the VM ( which is pretty cool ).
That's good.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> (This question is for Costin)
>
> As I've mentioned before, I'm writing a new mapper to replace the
> current 5.0 request mapper, which is a major performance problem right
> now.
>
> The implementation goes well enough (I'll likely commit something today
> or tomorrow; in the end, there are no fancy algorithms involved), but
> there's the problem of keeping the mapper structure in sync with
> Catalina's structure.
>
> To do that, I was planning to use a simple MBean registration listener
> (as all the components we're interested in register with JMX) with the
> MBean server. (I can only see a way of doing that using JMX 1.2)
>
> So, is it ok to do that ? Is there a better way (I don't want to use the
> Catalina listeners, obviously) ?
If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.lang.String; instead of
java.lang.String[] ). And of course - fix download to get jmxri instead
of mx4j.
When MX4J implements 1.2, we'll switch back.
I'm using JMXRI1.2 - and so far it works very nice.
Regarding the registration listener: there are 2 issues you need to
be carefull. First, it would be good if the code is independent of
the load order - i.e. listen for notifications but also do a query for
the existing objects. You can do that using JMX query, or by
using the attributes. After you take care of the existing mappings,
you can start listening for registration - you can do both with plain
JMX1.1.
I don't know if all the components are registered - we do have the Context
and Servlet, but you'll need to make sure the Context mbean is exposing the
mappings. Unfortunately JSR77 ( or other standards I know ) do not define
any standard attribute that a "WebModule" mbean would use to expose
supported mappings - so the code will remain dependent of catalina, but
with less cupling.
BTW, I am now able to create Context mbeans and have them registered
automatically - and I'll try to get the same working for Valves, Connectors
and JkHandlers. If this is used with an mbean server that supports
reloading ( like jboss.mx ) - we'll be able to replace modules without
restarting the VM ( which is pretty cool ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
(This question is for Costin)
As I've mentioned before, I'm writing a new mapper to replace the
current 5.0 request mapper, which is a major performance problem right now.
The implementation goes well enough (I'll likely commit something today
or tomorrow; in the end, there are no fancy algorithms involved), but
there's the problem of keeping the mapper structure in sync with
Catalina's structure.
To do that, I was planning to use a simple MBean registration listener
(as all the components we're interested in register with JMX) with the
MBean server. (I can only see a way of doing that using JMX 1.2)
So, is it ok to do that ? Is there a better way (I don't want to use the
Catalina listeners, obviously) ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [ANN] Security update: Apache Tomcat 3.3.1a released
Posted by Bill Barker <wb...@wilshire.com>.
I'm assuming that this was actually voted on in some list (certainly not
this one). I'd just like to add my -0 vote (only because a -1 is pointless
now :). The 3.3 branch needs to have a 3.3.2 release, and IMHO, a 3.3.1a
release is just a waste of time.
----- Original Message -----
From: "Larry Isaacs" <La...@sas.com>
To: <to...@jakarta.apache.org>; <to...@jakarta.apache.org>;
<an...@jakarta.apache.org>
Sent: Saturday, January 25, 2003 8:30 PM
Subject: [ANN] Security update: Apache Tomcat 3.3.1a released
Tomcat 3.3.1a has been released to address the following two
vulnerabilities found in Tomcat 3.3.1 and earlier. This
includes Tomcat 3.2.4 and earlier.
Tomcat 4.0.4, 4.0.6, 4.1.12, 4.1.18, and 4.1.19 have been
checked and do not have these vulnerabilities.
Vulnerability where, when used with JDK 1.3.1 or earlier, a
maliciously crafted request could return a directory listing
even when an index.html, index.jsp, or other welcome file is
present. File contents can be returned as well. In the case
of Tomcat 3.2.4 and earlier, contents of files under WEB-INF
could be accessed. If you are using Tomcat 3.3.1 or earlier
with JDK 1.3.1 or earlier, you should either upgrade to JDK 1.4
or later, or upgrade your Tomcat installation to Tomcat 3.3.1a
or a current release of Tomcat 4.
Vulnerability where a malicious web application could read the
contents of some files outside the web application via its web.xml
file in spite of the presence of a security manager. The content
of files that can be read as part of an XML document would be
accessible. If you are running Tomcat 3.3.1 or earlier with a
security manager, and are serving web applications whose web.xml
content is not known to be safe, you should upgrade your Tomcat
installation to 3.3.1a or a current release of Tomcat 4.
You may download Tomcat 3.3.1a binaries and updated jars from:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3.1a/bin/
Other Tomcat downloads may be obtained from:
http://jakarta.apache.org/site/binindex.cgi
These vulnerabilities have been fixed in the current Tomcat 3.3.2-dev
files found at:
http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/
Larry
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Configuration Variables
Posted by Jim Henderson <jg...@metafile.com>.
I can not seem to find this in my books, can someone explain this?
What WAR file web.xml parameter can be used to pass application wide (not
just a single Servlet or JSP) configuration data to JSP/Servlet that also is
adjustable from Tomcat-Administrator control page, and what Java methods
(xxx.getYyyy("parmName")) do I use to access the data given the parameter
name? I would like to access the parameter from the program at any time,
and not just when the Servlet is loaded (init time).
I wish the O'Reilly book clearly explained the relationships of the Java
accessor methods, the web.xml parameters, and the Tomcat Admin options. I
seem to have gone round and round with this and now I'm lost.
Thanks!