Re: [Fwd: [SECURITY ISSUE] Using allowLinking with deprecated HTTP 1.1 connector]

2005-02-24 Thread Stefan Bodewig
I have no idea where the original thread happened, at least I didn't
see any mails before this one.

On Wed, 23 Feb 2005, robert burrell donkin [EMAIL PROTECTED] wrote:

 i wonder whether henri might be able to bring this up (either
 formally or informally) with aim of discovering whether jakarta in
 general and tomcat in particular have the right structures in place
 and what improvements we might make.

The structures are pretty well defined.  Each project is supposed to
have at least one security liaison that the security committee knows
about.  Incoming security issues are supposed to go through this
liaison, but recent mails to the PMC list suggest it doesn't happen
that way.

 Having just dealt with the issue below I was thinking where else,
 other than the Tomcat User mailing list this information needed to
 be sent?

[EMAIL PROTECTED] and [EMAIL PROTECTED], IMHO.  This along with a new
Tomcat release that fixes the issue.

From my experience fix = release = announce is the process used by
other projects, including httpd.  And from an end-user standpoint the
process that makes sense the most.

 2. Do we publish anywhere a list of known security issues and
 their associated fixes? If yes, where? If not, should we?

I think we should follow the httpd way
http://httpd.apache.org/security_report.html is linked from the main
navigation.  If you look into one of the pages linked from there, it
goes to apacheweek for some reasin, but we should be able to produce
the same sort of content ourselves.

 Not that I know. I'd assume it'd be a Tomcat page somewhere?

+1

Stefan

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



Re: [Fwd: [SECURITY ISSUE] Using allowLinking with deprecated HTTP 1.1 connector]

2005-02-23 Thread robert burrell donkin
it may well be wiser to discuss these matters on lists which are not 
public.

brian's usually very well informed about such matters. i wonder whether 
henri might be able to bring this up (either formally or informally) 
with aim of discovering whether jakarta in general and tomcat in 
particular have the right structures in place and what improvements we 
might make.

- robert
On 22 Feb 2005, at 02:23, Henri Yandell wrote:
On Mon, 21 Feb 2005, Mark Thomas wrote:
Hi,
Having just dealt with the issue below I was thinking where else, 
other than the Tomcat User mailing list this information needed to be 
sent? That got me thinking about the wider issue of handling security 
issues at Jakarta/Apache. I went looking for, but failed to find, 
answers to the following questions:

1. Does anyone monitor the issues reported to [EMAIL PROTECTED] to 
ensure that they are evaluated and, if necessary addressed, in a 
timely manner? If yes, who? If not, should we?
I think the httpd folks tend to monitor [EMAIL PROTECTED], and forward 
Tomcat specific ones over to the [EMAIL PROTECTED] list. There've been a 
couple of emails that have processed that way.

2. Do we publish anywhere a list of known security issues and their 
associated fixes? If yes, where? If not, should we?
Not that I know. I'd assume it'd be a Tomcat page somewhere? So much 
of Jakarta/Apache is outside the obvious realm of security issues that 
I think it's probably a (sub-)community based issue.

Does anyone here know the answers to these questions?
I don't :)
I imagine Tomcat should approach things with the same stance that 
Httpd has towards such issues (whatever that is), and possibly get a 
couple of people on [EMAIL PROTECTED] if they're not already.

Hen
 Original Message 
From: Mark Thomas [EMAIL PROTECTED]
All,
A security issue has come to light where a mal-formed request may 
result
in JSP source code disclosure.

This issue only applies if all of the following are true:
1. You are using any Tomcat 4 version = 4.1.15
2. You are using the deprecated HTTP 1.1 connector
(org.apache.catalina.connector.http.HttpConnector)
3. You have configured 1 or more contexts served by the connector 
with a
resources element that uses the allowLinking parameter and this
parameter is set to true.

The fix is to use the Coyote HTTP connector
(org.apache.coyote.tomcat4.CoyoteConnector).
The on-line Tomcat 4 docs have been updated to include a warning about
this configuration combination. The next Tomcat 4 release will include
the updated documentation.
If you are using Tomcat 4 with the standard Coyote HTTP connector this
issue does not apply.
Tomcat 5.0.x and 5.5.x are unaffected by this issue.
Thanks are due to Glenn Choat who reported this issue to the Tomcat 
team
last week.

As a reminder, if you have a verified security bug to report please do
not post it to email lists or submit a bug report. Security bugs 
should
be reported privately by email to [EMAIL PROTECTED]

Regards,
Mark
-
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]
-
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]


[Fwd: [SECURITY ISSUE] Using allowLinking with deprecated HTTP 1.1 connector]

2005-02-21 Thread Mark Thomas
Hi,
Having just dealt with the issue below I was thinking where else, other 
than the Tomcat User mailing list this information needed to be sent? 
That got me thinking about the wider issue of handling security issues 
at Jakarta/Apache. I went looking for, but failed to find, answers to 
the following questions:

1. Does anyone monitor the issues reported to [EMAIL PROTECTED] to 
ensure that they are evaluated and, if necessary addressed, in a timely 
manner? If yes, who? If not, should we?

2. Do we publish anywhere a list of known security issues and their 
associated fixes? If yes, where? If not, should we?

Does anyone here know the answers to these questions?
Mark
 Original Message 
From: Mark Thomas [EMAIL PROTECTED]
All,
A security issue has come to light where a mal-formed request may result
in JSP source code disclosure.
This issue only applies if all of the following are true:
1. You are using any Tomcat 4 version = 4.1.15
2. You are using the deprecated HTTP 1.1 connector
(org.apache.catalina.connector.http.HttpConnector)
3. You have configured 1 or more contexts served by the connector with a
resources element that uses the allowLinking parameter and this
parameter is set to true.
The fix is to use the Coyote HTTP connector
(org.apache.coyote.tomcat4.CoyoteConnector).
The on-line Tomcat 4 docs have been updated to include a warning about
this configuration combination. The next Tomcat 4 release will include
the updated documentation.
If you are using Tomcat 4 with the standard Coyote HTTP connector this
issue does not apply.
Tomcat 5.0.x and 5.5.x are unaffected by this issue.
Thanks are due to Glenn Choat who reported this issue to the Tomcat team
 last week.
As a reminder, if you have a verified security bug to report please do
not post it to email lists or submit a bug report. Security bugs should
be reported privately by email to [EMAIL PROTECTED]
Regards,
Mark
-
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: [Fwd: [SECURITY ISSUE] Using allowLinking with deprecated HTTP 1.1 connector]

2005-02-21 Thread Henri Yandell

On Mon, 21 Feb 2005, Mark Thomas wrote:
Hi,
Having just dealt with the issue below I was thinking where else, other than 
the Tomcat User mailing list this information needed to be sent? That got me 
thinking about the wider issue of handling security issues at Jakarta/Apache. 
I went looking for, but failed to find, answers to the following questions:

1. Does anyone monitor the issues reported to [EMAIL PROTECTED] to ensure 
that they are evaluated and, if necessary addressed, in a timely manner? If 
yes, who? If not, should we?
I think the httpd folks tend to monitor [EMAIL PROTECTED], and forward 
Tomcat specific ones over to the [EMAIL PROTECTED] list. There've been a couple 
of emails that have processed that way.

2. Do we publish anywhere a list of known security issues and their 
associated fixes? If yes, where? If not, should we?
Not that I know. I'd assume it'd be a Tomcat page somewhere? So much of 
Jakarta/Apache is outside the obvious realm of security issues that I 
think it's probably a (sub-)community based issue.

Does anyone here know the answers to these questions?
I don't :)
I imagine Tomcat should approach things with the same stance that Httpd 
has towards such issues (whatever that is), and possibly get a couple of 
people on [EMAIL PROTECTED] if they're not already.

Hen
 Original Message 
From: Mark Thomas [EMAIL PROTECTED]
All,
A security issue has come to light where a mal-formed request may result
in JSP source code disclosure.
This issue only applies if all of the following are true:
1. You are using any Tomcat 4 version = 4.1.15
2. You are using the deprecated HTTP 1.1 connector
(org.apache.catalina.connector.http.HttpConnector)
3. You have configured 1 or more contexts served by the connector with a
resources element that uses the allowLinking parameter and this
parameter is set to true.
The fix is to use the Coyote HTTP connector
(org.apache.coyote.tomcat4.CoyoteConnector).
The on-line Tomcat 4 docs have been updated to include a warning about
this configuration combination. The next Tomcat 4 release will include
the updated documentation.
If you are using Tomcat 4 with the standard Coyote HTTP connector this
issue does not apply.
Tomcat 5.0.x and 5.5.x are unaffected by this issue.
Thanks are due to Glenn Choat who reported this issue to the Tomcat team
last week.
As a reminder, if you have a verified security bug to report please do
not post it to email lists or submit a bug report. Security bugs should
be reported privately by email to [EMAIL PROTECTED]
Regards,
Mark
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]