Re: Proposed new security pages
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Good stuff. Minor typo in the 5-x page: >If directory listings are enabled, >a diretcory listing will be shown. ^^ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Filip Hanik - Dev Lists wrote: Yoav Shapira wrote: Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Yoav Shapira wrote: Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Yoav Shapira wrote: Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Hi, On 2/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Hi, On 2/15/07, Mark Thomas <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Good idea. +1 2007/2/16, Mark Thomas <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]