Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 25BF610A6C for ; Tue, 14 Jan 2014 19:06:30 +0000 (UTC) Received: (qmail 14605 invoked by uid 500); 14 Jan 2014 19:06:28 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 14541 invoked by uid 500); 14 Jan 2014 19:06:28 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 14533 invoked by uid 99); 14 Jan 2014 19:06:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 19:06:28 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.215.43 as permitted sender) Received: from [209.85.215.43] (HELO mail-la0-f43.google.com) (209.85.215.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 19:06:22 +0000 Received: by mail-la0-f43.google.com with SMTP id er20so650447lab.16 for ; Tue, 14 Jan 2014 11:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Em6d6Or8b4tmmgFBaWthYsdfuRd929zejOttsoV10I0=; b=dU9tTm/MzmRI2wQ+Oo6HLyTkagKu3a/x04vIVlGuj2c7V7oJEtpyIseYGSlHBfmmJj bNHLAhzrLhq4uUSbTOxx84Hu59Xljz7kmnVwBxWRJEB9QWqaxCA0z1xzJPvo1td2cL1U GC47C55vfEVdpCNdI0uOrttIbZj8iQnvRMaafcqziRacl/7eHVe79y4GbTRVkf9yji7+ jLmOdRIGNW7IHICeKBTQNvzaEk624ZjBKcPo+BKUd/XB/wsxtwZ3o04jirQ3Byd2a3qi zSzaQFfmud+0i2Lrld3o7ppKN2ZSnKkkrGb5gIG1hUqtKKu+eN2f4StabIHxHG9PGz+D AEFg== MIME-Version: 1.0 X-Received: by 10.152.167.103 with SMTP id zn7mr1447946lab.68.1389726361853; Tue, 14 Jan 2014 11:06:01 -0800 (PST) Received: by 10.114.11.170 with HTTP; Tue, 14 Jan 2014 11:06:01 -0800 (PST) In-Reply-To: <52D57A67.5070308@reser.org> References: <52D0F812.8050907@reser.org> <52D4D4CB.1070000@reser.org> <52D57A67.5070308@reser.org> Date: Tue, 14 Jan 2014 14:06:01 -0500 Message-ID: Subject: Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities From: Jeff Trawick To: Apache HTTP Server Development List Content-Type: multipart/alternative; boundary=001a1136d9e222395404eff2e27a X-Virus-Checked: Checked by ClamAV on apache.org --001a1136d9e222395404eff2e27a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 14, 2014 at 12:56 PM, Ben Reser 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/ --001a1136d9e222395404eff2e27a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 14, 2014 at 12:56 PM, Ben Reser <ben@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." =A0The RM commits the fixes= just before Tag
> & Roll and, depending on the impact of the vulnerabilities, may ca= ll for an
> abbreviated testing schedule.

That really doesn't answer any of the questions I just asked. =A0= If I thought the
existing process handled all of this I wouldn't have asked the question= s.

I suggest starting a new thread abou= t a particular aspect of handling security issues that should be discussed.=
=A0

> This is back to choice 1 or choice 2, and whether or not you think tha= t showing
> the code gives a would-be attacker useful information.

Committing the code always gives a would-be attacker useful informati= on, I
don't dispute that. =A0The distinction is that committing a CVE number = with a
security fix gives them MORE information. =A0It creates the opportunity to<= br> automate detection of fixes that can be analyzed and exploited before we ca= n
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. =A0Note that many h= ttpd vulnerabilities are scoped to specific features that can be potentiall= y disabled (if in fact they are in use in a particular configuration).
=A0

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 ope= n source
project. =A0And less critical issues can afford a larger gap than more crit= ical
issues. =A0However, that gap should be no more than a few days in my opinio= n.
Certainly not weeks or months.

> The vote is about reaffirming support for and documenting a long-stand= ing
> practice around commit/disclosure which has been followed in the vast = majority
> of cases and which most of us feel should always be followed. =A0It is= not about
> inventing completely new procedures to deal with vulnerabilities.

My observation has been that we haven't been doing that. =A0I dec= ided to go back
and look at what we've been doing. =A0I 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
=A0 =A0 =A0 =A0 trunk revision: 1485668 (2013-05-23)
=A0 =A0 =A0 =A0 CVE in commit: no CVE (even now)
=A0 =A0 =A0 =A0 comments: mentions segfault
=A0 =A0 =A0 =A0 release with fix: 2013-07-22

CVE-2013-2249
=A0 =A0 =A0 =A0 trunk revision: 1488158 (2013-05-31)
=A0 =A0 =A0 =A0 CVE in commit: no CVE (even now)
=A0 =A0 =A0 =A0 comments: doesn't mention security impact at all
=A0 =A0 =A0 =A0 release with fix: 2013-07-22

CVE-2012-3499
=A0 =A0 =A0 =A0 trunk revision: 1413732 (2012-11-26) & 1418752 (2012-12= -08)
=A0 =A0 =A0 =A0 CVE in commit: no CVE (even now)
=A0 =A0 =A0 =A0 comments: only says missing html escaping
<= div>
A pretty broad set of users recognizes the type of conce= rn when they see text about html escaping; I'm not sure if the obfuscat= ion in "Be sure = to escape potential troubled srings" in the first commit is purposeful= or accidental :)

=A0
=A0 =A0 =A0 =A0 release with fix: 2013-02-25

CVE-2012-4558
=A0 =A0 =A0 =A0 trunk revision: 1413732 (2012-11-26)
=A0 =A0 =A0 =A0 CVE in commit: no CVE (even now)
=A0 =A0 =A0 =A0 comments: only says missing html escaping
<= div>
same comment as above
=A0
=A0 =A0 =A0 =A0 release with fix: 2013-02-25

CVE-2012-3502
=A0 =A0 =A0 =A0 trunk revision: 1373955 (2012-08-16)
=A0 =A0 =A0 =A0 CVE in commit: no CVE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 original version:
http:= //mail-archives.apache.org/mod_mbox/httpd-cvs/201208.mbox/%3C20120816175451= .51AC32388900%40eris.apache.org%3E
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 has been updated since to include CVE
=A0 =A0 =A0 =A0 comments: no mention of security impact in initial commit, = subsequent update
is good
=A0 =A0 =A0 =A0 release with fix: 2012-08-21

CVE-2012-2687
=A0 =A0 =A0 =A0 trunk revision: 1349905 (2012-06-13)
=A0 =A0 =A0 =A0 CVE in commit: CVE in initial commit
=A0 =A0 =A0 =A0 comments: Good explanation of security issue
=A0 =A0 =A0 =A0 release with fix: 2012-08-21

CVE-2012-0883
=A0 =A0 =A0 =A0 trunk revision: 1296428 (2012-03-02)
=A0 =A0 =A0 =A0 CVE in commit: CVE in initial commit
=A0 =A0 =A0 =A0 comments: Explanation done in initial commit
=A0 =A0 =A0 =A0 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. =A0From 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). =A0To that end I appl= aud
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 p= artial disclosure cases above are examples of a secondary problem with part= ial disclosure that someone else mentioned -- We're forgetting to fix a= ll of the doc after the fact in some cases where the fix was purposefully p= ut in without describing the impact. =A0But 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 whet= her or
> not a vulnerability can be fully disclosed prior to the time a release= is
> prepared. =A0If it can, commit away. =A0If not, wait for Tag&Roll.=

I acknowledged that my questions went beyond the simple question in y= our vote.
=A0The 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 explaine= d in the
commit message and without an advisory and/or release coming out very soon = is
ever really helpful towards that goal. =A0Our users do not read our commits= ,
probably do not understand what our commit messages mean with respect to im= pact
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.)

F= WIW, 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 c= onfiguration, they just have to ask. =A0And there is an official patches di= rectory that occasionally we use to make it easier for users to patch exist= ing versions with vulnerability fixes, but that is another tangent that pro= bably could be described as "A separate patch will be supplied for exi= sting releases if it is championed by any httpd committer who obtains the r= equired reviews. =A0Patches are most commonly provided when the vulnerabili= ty is severe or there are potential considerations with adopting a new vers= ion which includes the fix, but patches are not limited to those cases.&quo= t;
=A0

I'm approaching this from the standpoint of helping our users as much a= s possible.



--
Born in Rosw= ell... married an alien...
http://emptyhammock.com/
--001a1136d9e222395404eff2e27a--