Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of ben@reser.org designates
 50.197.89.41 as permitted sender)
Message-ID: <52D57A67.5070308@reser.org>
Date: Tue, 14 Jan 2014 09:56:55 -0800
From: Ben Reser <ben@reser.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to
 vulnerabilities
References: 
 <CAKUrXK5mp1Lgib0u4-AjGy1MsvZ6FfLqDA6T-OHZzQRy1OU-_g@mail.gmail.com>
	<52D0F812.8050907@reser.org>
	<CAKUrXK5RDRC16wrD1O-0XfVHOO_80ksgDgTmrxM79e3EBAErsg@mail.gmail.com>
	<52D4D4CB.1070000@reser.org>
 <CAKUrXK4ihBcO5FJFsoGGexN-8sMu82AacOFnhDa7-QuW8q_xFw@mail.gmail.com>
In-Reply-To: 
 <CAKUrXK4ihBcO5FJFsoGGexN-8sMu82AacOFnhDa7-QuW8q_xFw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

> 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.

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
	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
	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.

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'm approaching this from the standpoint of helping our users as much as possible.