On Tue, Jan 14, 2014 at 12:56 PM, Ben Reser <b...@reser.org> wrote: > On 1/14/14, 7:35 AM, Jeff Trawick wrote: > > The simple answer to all of this is "look how httpd releases with > security > > fixes have been handled in the past." The RM commits the fixes just > before Tag > > & Roll and, depending on the impact of the vulnerabilities, may call for > an > > abbreviated testing schedule. > > That really doesn't answer any of the questions I just asked. If I > thought the > existing process handled all of this I wouldn't have asked the questions. >
I suggest starting a new thread about a particular aspect of handling security issues that should be discussed. > > > This is back to choice 1 or choice 2, and whether or not you think that > showing > > the code gives a would-be attacker useful information. > > Committing the code always gives a would-be attacker useful information, I > don't dispute that. The distinction is that committing a CVE number with a > security fix gives them MORE information. It creates the opportunity to > automate detection of fixes that can be analyzed and exploited before we > can > get fixes in the hands of our users. > It also allows a broader set of users to determine if they have an impact at the same time that would-be hackers can determine that. Note that many httpd vulnerabilities are scoped to specific features that can be potentially disabled (if in fact they are in use in a particular configuration). > > If you don't narrow the gap between that commit and putting the fix in a > usable > state to end users then you've harmed our users rather than helped them in > my > opinion. > > There will always be some sort of gap, that's just the nature of an open > source > project. And less critical issues can afford a larger gap than more > critical > issues. However, that gap should be no more than a few days in my opinion. > Certainly not weeks or months. > > > The vote is about reaffirming support for and documenting a long-standing > > practice around commit/disclosure which has been followed in the vast > majority > > of cases and which most of us feel should always be followed. It is not > about > > inventing completely new procedures to deal with vulnerabilities. > > My observation has been that we haven't been doing that. I decided to go > back > and look at what we've been doing. I only bothered to look at 2.4.x > (which I > realize is not a huge sample). > > Here's how we've done with 2.4.x so far: > CVE-2013-1896 > trunk revision: 1485668 (2013-05-23) > CVE in commit: no CVE (even now) > comments: mentions segfault > release with fix: 2013-07-22 > > CVE-2013-2249 > trunk revision: 1488158 (2013-05-31) > CVE in commit: no CVE (even now) > comments: doesn't mention security impact at all > release with fix: 2013-07-22 > > CVE-2012-3499 > trunk revision: 1413732 (2012-11-26) & 1418752 (2012-12-08) > CVE in commit: no CVE (even now) > comments: only says missing html escaping > A pretty broad set of users recognizes the type of concern when they see text about html escaping; I'm not sure if the obfuscation in "Be sure to escape potential troubled srings" in the first commit is purposeful or accidental :) > release with fix: 2013-02-25 > > CVE-2012-4558 > trunk revision: 1413732 (2012-11-26) > CVE in commit: no CVE (even now) > comments: only says missing html escaping > same comment as above > release with fix: 2013-02-25 > > CVE-2012-3502 > trunk revision: 1373955 (2012-08-16) > CVE in commit: no CVE > original version: > > http://mail-archives.apache.org/mod_mbox/httpd-cvs/201208.mbox/%3C20120816175451.51AC32388900%40eris.apache.org%3E > has been updated since to include CVE > comments: no mention of security impact in initial commit, > subsequent update > is good > release with fix: 2012-08-21 > > CVE-2012-2687 > trunk revision: 1349905 (2012-06-13) > CVE in commit: CVE in initial commit > comments: Good explanation of security issue > release with fix: 2012-08-21 > > CVE-2012-0883 > trunk revision: 1296428 (2012-03-02) > CVE in commit: CVE in initial commit > comments: Explanation done in initial commit > release with fix: 2012-04-17 > > Now the last couple actually do commit with a CVE number and an > exmplation, so > maybe I'm wrong and this has been a long standing practice. From the > limited > data of 2.4.x it looks like something changed (or maybe it's just some > people > do things one way and another group does it another). To that end I > applaud > your effort to standardize what's being done. > I didn't realize there were as many cases; I had remembered just a couple of recent ones. All but one of the partial disclosure cases above are examples of a secondary problem with partial disclosure that someone else mentioned -- We're forgetting to fix all of the doc after the fact in some cases where the fix was purposefully put in without describing the impact. But we eventually fixed CHANGES in all cases, which is the more important piece. > Maybe the people committing obscured logs were following this page: > http://www.apache.org/security/committers.html > > But up till now I've been approaching this as a change in policy since > that's > how it appeared to me based on the above. > > > For this small aspect of the overall policy that is being voted on, > > implementation is as simple as having the security team determine > whether or > > not a vulnerability can be fully disclosed prior to the time a release is > > prepared. If it can, commit away. If not, wait for Tag&Roll. > > I acknowledged that my questions went beyond the simple question in your > vote. > The goal as I understand it is to avoid security by obscurity and to put > our > users on a equal footing to potential attackers reading our source commits. > > I don't think ever committing with some sort of security issue explained > in the > commit message and without an advisory and/or release coming out very soon > is > ever really helpful towards that goal. Our users do not read our commits, > probably do not understand what our commit messages mean with respect to > impact > and may not be able to apply the fix committed (especially if it doesn't > easily > apply to release branches). > (I don't see any sort of agreement ever on this point.) FWIW, If somebody that sees such info can't apply a vulnerability fix to their httpd or they can't determine if a vulnerability impacts their configuration, they just have to ask. And there is an official patches directory that occasionally we use to make it easier for users to patch existing versions with vulnerability fixes, but that is another tangent that probably could be described as "A separate patch will be supplied for existing releases if it is championed by any httpd committer who obtains the required reviews. Patches are most commonly provided when the vulnerability is severe or there are potential considerations with adopting a new version which includes the fix, but patches are not limited to those cases." > > I'm approaching this from the standpoint of helping our users as much as > possible. > -- Born in Roswell... married an alien... http://emptyhammock.com/
