You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2007/02/16 04:34:14 UTC
Proposed new security pages
All,
I have started to put together some additional security pages based on
httpd. I have only added text for a couple vulnerabilities but the
plan is to include all those in the CVE list plus any I can find in
the archives.
The draft is currently on people.a.o at
http://people.apache.org/~markt/tomcat-security/security.html
My plan is to commit as is and then work through the CVE list. Once I
have all the CVE entries I'll remove the work in progress comment at
the top of the first page and then start searching the archives and
other public vulnerability databases.
Any comments before I commit these changes to the live site?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Mark Thomas <ma...@apache.org>.
Jean-Frederic wrote:
> On Thu, 2007-02-15 at 22:34 -0500, Mark Thomas wrote:
>> Any comments before I commit these changes to the live site?
>
> Add a mod_jk Apache Tomcat JK
Done, with information about the recently announced issue.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Jean-Frederic <jf...@gmail.com>.
On Thu, 2007-02-15 at 22:34 -0500, Mark Thomas wrote:
> All,
>
> I have started to put together some additional security pages based on
> httpd. I have only added text for a couple vulnerabilities but the
> plan is to include all those in the CVE list plus any I can find in
> the archives.
>
> The draft is currently on people.a.o at
> http://people.apache.org/~markt/tomcat-security/security.html
>
> My plan is to commit as is and then work through the CVE list. Once I
> have all the CVE entries I'll remove the work in progress comment at
> the top of the first page and then start searching the archives and
> other public vulnerability databases.
>
> Any comments before I commit these changes to the live site?
Add a mod_jk Apache Tomcat JK
+1
Cheers
Jean-Frederic
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Henri Gomez <he...@gmail.com>.
Good idea.
+1
>2007/2/16, Mark Thomas <ma...@apache.org>:
> All,
>
> I have started to put together some additional security pages based on
> httpd. I have only added text for a couple vulnerabilities but the
> plan is to include all those in the CVE list plus any I can find in
> the archives.
>
> The draft is currently on people.a.o at
> http://people.apache.org/~markt/tomcat-security/security.html
>
> My plan is to commit as is and then work through the CVE list. Once I
> have all the CVE entries I'll remove the work in progress comment at
> the top of the first page and then start searching the archives and
> other public vulnerability databases.
>
> Any comments before I commit these changes to the live site?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 2/15/07, Mark Thomas <ma...@apache.org> wrote:
> I have started to put together some additional security pages based on
> httpd. I have only added text for a couple vulnerabilities but the
> plan is to include all those in the CVE list plus any I can find in
> the archives.
>
> The draft is currently on people.a.o at
> http://people.apache.org/~markt/tomcat-security/security.html
Great stuff, +1.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Mark Thomas <ma...@apache.org>.
Ian Darwin wrote:
> Good stuff. Minor typo in the 5-x page:
>
>>If directory listings are enabled,
>>a diretcory listing will be shown.
Thanks. Fixed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Ian Darwin <ia...@darwinsys.com>.
Good stuff. Minor typo in the 5-x page:
>If directory listings are enabled,
>a diretcory listing will be shown.
^^
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> and with all this crap said, I'm ok either way. Not trying to convince
> anyone, I just thought that we should provide our users with the same
> "delay"-courtesy that we would expect a reporting body to provide for us
I didn't pick this up before. What do you mean? That we cut a
release that includes the fix, but not announce the fix in the release
notes until a while later? Or that we let downstream packagers like
RedHat know before we cut a binary release? Or both? I suppose
either or both could be OK...
I don't think we disagree on much. We agree we should resolve these
issues as fast as possible, with as much coordination as possible with
both those people reporting the issues and those downstream (our users
and (re)packagers) as possible to eliminate bad surprises. The fix
has to be in SVN first, by definition, before any release is cut, and
then I think we agree a release including the fix should be cut as
fast as possible. I think we agree on all this, and only the issue of
the release being voted as stable before public announcement, which is
a fairly minor point in this whole process, is up for debated.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Filip Hanik - Dev Lists wrote:
> Yoav Shapira wrote:
>> Hi,
>>
>> On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>>> The consequence of this is that you are "advertising" a security
>>> vulnerability to the world, and you are leaving your users with either
>>> continue running a stable version that everyone knows how to exploit or
>>> to upgrade to a non stable version.
>>>
>>> Doesn't sound like a fair choice, does it?
>>
>> The first, and default choice for security-conscious users, is to
>> apply the patch directly from SVN without even waiting for a release.
>> This follows the practice httpd has been following for many years, and
>> they document it well: see for example
>> http://www.apacheweek.com/issues/04-06-11 .
> yes, I can see a few folks doing this. But I believe most folks still
> get the updated binaries from their distribution source.
> for example, RedHat will apply the actual patch and rebuild for their
> distro, others will do the same.
>
>>
>> If someone is security-conscious, they should look at the SVN details
>> that will be announced when we publish a vulnerability, and see for
>> themselves whether they want to update or not. If they do want to
>> update, they'll do so immediately right from the source, and waiting
>> for us to release, much less waiting for us to vote on a release, is
>> spurious.
> you assume that companies know how to "patch" a release, build etc.
> some do, some don't. Some that do, still prefer to get a binary.
>>
>> In general, we can't assume the release following a security
>> vulnerability announcement, x.y.(z+1) in your example, will be stable
>> for a long long time, unless someone wants to do a release not from
>> the trunk, but from the tag of the previous stable release. That
>> someone, e.g. you if you're interested, is welcome to do that work.
>> But I think it's a waste of time because of the above source update
>> option, and therefore shouldn't be our mandated practice.
>>
>> Also one other note: our putting a security vulnerability notice is
>> not likely to be the first publication of such notice. In most cases,
>> the original person or entity who discovered the vulnerability will
>> report it to such bodies as CVE, which are watched by a lot more
>> people (good and bad) than the Tomcat mailing lists.
> really, I was under the impression that most bodies that report a
> security issue,
> will not publish until you OK them to do so.
> For example, the security problem in the JDK, was reported over a year
> before Sun actually released the fix.
> First when Sun had a JDK version available, was the vulnerability
> released. We're not talking weeks in this particular case, rather months.
> And I would assume that most reporting bodies follow the same
> practices. Am I wrong?
and with all this crap said, I'm ok either way. Not trying to convince
anyone, I just thought that we should provide our users with the same
"delay"-courtesy that we would expect a reporting body to provide for us
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> yes, I can see a few folks doing this. But I believe most folks still
> get the updated binaries from their distribution source.
> for example, RedHat will apply the actual patch and rebuild for their
> distro, others will do the same.
Let RedHat get the patch and build whatever they want, whenever they
want: that doesn't mean we have to do a binary release, much less wait
for a stable one. Especially since they're going from source anyways.
I also wasn't talking about "most folks" (though by the way, it's a
long way from "I believe" to concrete data showing what "most folks"
do). I was talking about those who are security-conscious and care
about these vulnerabilities, many of which are highly theoretical in
nature. Those people, in my experience, are considerably more savvy
than our average user.
> you assume that companies know how to "patch" a release, build etc.
> some do, some don't. Some that do, still prefer to get a binary.
See above.
> really, I was under the impression that most bodies that report a
> security issue,
> will not publish until you OK them to do so.
Definitely not. At most, they will give you a courtesy period after
which they'll go ahead and publish, no matter whether you've had a
release or not. When I did my research thesis on this topic, mining
http://www.securityfocus.com/vulnerabilities for metadata, the
majority of security issues announced to the public did not have a fix
available, even in source code, much less a binary version, when the
vulnerability was published. One can easily confirm this by checking
out the entries on SecurityFocus.com or CVE and similar lists and
correlating them to release dates in software packages that include a
fix.
> For example, the security problem in the JDK, was reported over a year
> before Sun actually released the fix.
> First when Sun had a JDK version available, was the vulnerability
> released. We're not talking weeks in this particular case, rather months.
A very unusual exception.
> And I would assume that most reporting bodies follow the same practices.
> Am I wrong?
Definitely. I spent a few months researching this very process ;)
Also remember, what I said is not that we can't do binary releases for
security issues. It's perfectly fine to do these releases. All I'm
saying is:
- It shouldn't be mandated that we have a *stable* binary release
before the vulnerability is announced,
- The issue is likely to become public before a stable release is available
- People who really care about security will apply the patch from source
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Yoav Shapira wrote:
> Hi,
>
> On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>> The consequence of this is that you are "advertising" a security
>> vulnerability to the world, and you are leaving your users with either
>> continue running a stable version that everyone knows how to exploit or
>> to upgrade to a non stable version.
>>
>> Doesn't sound like a fair choice, does it?
>
> The first, and default choice for security-conscious users, is to
> apply the patch directly from SVN without even waiting for a release.
> This follows the practice httpd has been following for many years, and
> they document it well: see for example
> http://www.apacheweek.com/issues/04-06-11 .
yes, I can see a few folks doing this. But I believe most folks still
get the updated binaries from their distribution source.
for example, RedHat will apply the actual patch and rebuild for their
distro, others will do the same.
>
> If someone is security-conscious, they should look at the SVN details
> that will be announced when we publish a vulnerability, and see for
> themselves whether they want to update or not. If they do want to
> update, they'll do so immediately right from the source, and waiting
> for us to release, much less waiting for us to vote on a release, is
> spurious.
you assume that companies know how to "patch" a release, build etc.
some do, some don't. Some that do, still prefer to get a binary.
>
> In general, we can't assume the release following a security
> vulnerability announcement, x.y.(z+1) in your example, will be stable
> for a long long time, unless someone wants to do a release not from
> the trunk, but from the tag of the previous stable release. That
> someone, e.g. you if you're interested, is welcome to do that work.
> But I think it's a waste of time because of the above source update
> option, and therefore shouldn't be our mandated practice.
>
> Also one other note: our putting a security vulnerability notice is
> not likely to be the first publication of such notice. In most cases,
> the original person or entity who discovered the vulnerability will
> report it to such bodies as CVE, which are watched by a lot more
> people (good and bad) than the Tomcat mailing lists.
really, I was under the impression that most bodies that report a
security issue,
will not publish until you OK them to do so.
For example, the security problem in the JDK, was reported over a year
before Sun actually released the fix.
First when Sun had a JDK version available, was the vulnerability
released. We're not talking weeks in this particular case, rather months.
And I would assume that most reporting bodies follow the same practices.
Am I wrong?
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> The consequence of this is that you are "advertising" a security
> vulnerability to the world, and you are leaving your users with either
> continue running a stable version that everyone knows how to exploit or
> to upgrade to a non stable version.
>
> Doesn't sound like a fair choice, does it?
The first, and default choice for security-conscious users, is to
apply the patch directly from SVN without even waiting for a release.
This follows the practice httpd has been following for many years, and
they document it well: see for example
http://www.apacheweek.com/issues/04-06-11 .
If someone is security-conscious, they should look at the SVN details
that will be announced when we publish a vulnerability, and see for
themselves whether they want to update or not. If they do want to
update, they'll do so immediately right from the source, and waiting
for us to release, much less waiting for us to vote on a release, is
spurious.
In general, we can't assume the release following a security
vulnerability announcement, x.y.(z+1) in your example, will be stable
for a long long time, unless someone wants to do a release not from
the trunk, but from the tag of the previous stable release. That
someone, e.g. you if you're interested, is welcome to do that work.
But I think it's a waste of time because of the above source update
option, and therefore shouldn't be our mandated practice.
Also one other note: our putting a security vulnerability notice is
not likely to be the first publication of such notice. In most cases,
the original person or entity who discovered the vulnerability will
report it to such bodies as CVE, which are watched by a lot more
people (good and bad) than the Tomcat mailing lists.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Yoav Shapira wrote:
> Hi,
>
> On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>> sounds good, as long as we don't publish vulnerabilities until they are
>> indeed fix and the release has been voted stable
>
> Agreed except the "stable" part. When the vulnerabilities have been
> fixed in any release, including alpha / beta, they can be made public.
> If the security issue is urgent there's likely to be a release with
> nothing (or very little) except the security fix anyways. Those who
> need to upgrade urgently can do so.
And I don't see the reasoning in that. You can safely assume that most
corporations will only put a "stable" version in their production
environment.
So lets say that there is a security vulnerability that has been fixed
in x.y.(z+1) version, but that version also has some serious issues
qualifying it as a alpha.
The consequence of this is that you are "advertising" a security
vulnerability to the world, and you are leaving your users with either
continue running a stable version that everyone knows how to exploit or
to upgrade to a non stable version.
Doesn't sound like a fair choice, does it?
Filip
>
> Yoav
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
On 2/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> sounds good, as long as we don't publish vulnerabilities until they are
> indeed fix and the release has been voted stable
Agreed except the "stable" part. When the vulnerabilities have been
fixed in any release, including alpha / beta, they can be made public.
If the security issue is urgent there's likely to be a release with
nothing (or very little) except the security fix anyways. Those who
need to upgrade urgently can do so.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
sounds good, as long as we don't publish vulnerabilities until they are
indeed fix and the release has been voted stable
Filip
Mark Thomas wrote:
> All,
>
> I have started to put together some additional security pages based on
> httpd. I have only added text for a couple vulnerabilities but the
> plan is to include all those in the CVE list plus any I can find in
> the archives.
>
> The draft is currently on people.a.o at
> http://people.apache.org/~markt/tomcat-security/security.html
>
> My plan is to commit as is and then work through the CVE list. Once I
> have all the CVE entries I'll remove the work in progress comment at
> the top of the first page and then start searching the archives and
> other public vulnerability databases.
>
> Any comments before I commit these changes to the live site?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by Remy Maucherat <re...@apache.org>.
Mark Thomas wrote:
> All,
>
> I have started to put together some additional security pages based on
> httpd. I have only added text for a couple vulnerabilities but the
> plan is to include all those in the CVE list plus any I can find in
> the archives.
>
> The draft is currently on people.a.o at
> http://people.apache.org/~markt/tomcat-security/security.html
>
> My plan is to commit as is and then work through the CVE list. Once I
> have all the CVE entries I'll remove the work in progress comment at
> the top of the first page and then start searching the archives and
> other public vulnerability databases.
>
> Any comments before I commit these changes to the live site?
Ok. It's indeed a good idea.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposed new security pages
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Great stuff Mark!!! Thanks :)
Bill
Mark Thomas wrote:
> All,
>
> I have started to put together some additional security pages based on
> httpd. I have only added text for a couple vulnerabilities but the
> plan is to include all those in the CVE list plus any I can find in
> the archives.
>
> The draft is currently on people.a.o at
> http://people.apache.org/~markt/tomcat-security/security.html
>
> My plan is to commit as is and then work through the CVE list. Once I
> have all the CVE entries I'll remove the work in progress comment at
> the top of the first page and then start searching the archives and
> other public vulnerability databases.
>
> Any comments before I commit these changes to the live site?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org