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 9E6BC10150 for ; Tue, 14 Jan 2014 15:35:49 +0000 (UTC) Received: (qmail 65230 invoked by uid 500); 14 Jan 2014 15:35:47 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 65066 invoked by uid 500); 14 Jan 2014 15:35:46 -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 65054 invoked by uid 99); 14 Jan 2014 15:35:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 15:35:45 +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 (athena.apache.org: domain of trawick@gmail.com designates 209.85.217.174 as permitted sender) Received: from [209.85.217.174] (HELO mail-lb0-f174.google.com) (209.85.217.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 15:35:42 +0000 Received: by mail-lb0-f174.google.com with SMTP id p9so4656866lbv.19 for ; Tue, 14 Jan 2014 07:35:20 -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=xDpiW2j42MEVC45iFL9BoMv73TQ2K/adGRlg/Zu3XTo=; b=FBb9FkbQU6tIP2ut6MlWA1QBZMw2X0HnkVyxuuPB/kUvtop1vixjis5q2aQJDEjBzO ivE52WvbQXe7+JJPkFQFLIAcrWgSgnUvvxP/KCJCATtd7WFDL0KFowTkFuTbopjgEmtr BwmVn6p3aoEfItuMT0QSzg3pHZlA789NMT7lJb4lFVBlNlbCSNDRV4vsRfZAuc3GlkRU iVr3WQ/QUyvBKhtlUV/Bsfty8lpM9OrVrhthlqfGAh8uXU9MbxEESo/ud7NxRJmDDKk3 OgkBHb8EL8JP7X29b/fmU7PkBpGVxvi6vfrL1hSAwymiqCBB7PZOCkT2/8os+YCRxvKJ +vAQ== MIME-Version: 1.0 X-Received: by 10.112.162.232 with SMTP id yd8mr1225669lbb.12.1389713720320; Tue, 14 Jan 2014 07:35:20 -0800 (PST) Received: by 10.114.11.170 with HTTP; Tue, 14 Jan 2014 07:35:20 -0800 (PST) In-Reply-To: <52D4D4CB.1070000@reser.org> References: <52D0F812.8050907@reser.org> <52D4D4CB.1070000@reser.org> Date: Tue, 14 Jan 2014 10:35:20 -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=089e01184bbaa3aad404efeff034 X-Virus-Checked: Checked by ClamAV on apache.org --089e01184bbaa3aad404efeff034 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 14, 2014 at 1:10 AM, Ben Reser wrote: > On 1/11/14, 5:02 AM, Jeff Trawick wrote: > > I think a lot of your concerns revolve around assessment of when a > > vulnerability can be disclosed, and that has to be determined on a case > by case > > basis. The vote is just about whether there will be an in-between > situation > > where we share some information we have (the code change) without > sharing the > > rest, vs. deciding that, separate from the timing of how we release > information > > about a vulnerability, we either release all we have (code + impact) or > none of it. > > I guess my point is that there is a lot of process involved in not having > that > in-between situation. The vast majority of the situations do not present a > critical threat. It's a serious effort to take on that task. > > How do you see the release process working if you delay committing code > until > we're ready to announce the vulnerability? > > Are security advisories going to be separated from releases? > > Will the advisories include patches for released versions? If so does that > constitute a release and require a vote? If so how does that vote take > place? > > If we're not putting out advisories when the code is committed, how do we > expect users to know about the fixes? > > If we're not putting out releases with the advisories: For users that are > dependent on only using released version (binary packages that don't patch, > have policies against patching, etc...) are we committed to limiting the > time > between that code commit/advisory and a release version? Are we committed > to > releasing all supported versions at roughly the same time? Are we not > concerned that we're increasing the time frame that these users receive the > fixes since there is now a gap between us describing the vulnerability and > the > release being available to package. > 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. > > I know there are fixes that impact security that slip through the gaps. > Compare this change (which was handled as a security issue): > *) SECURITY: CVE-2013-1896 (cve.mitre.org) > mod_dav: Sending a MERGE request against a URI handled by mod_dav_svn > with > the source href (sent as part of the request body as XML) pointing to > a > URI that is not configured for DAV will trigger a segfault. [Ben Reser > ] > > vs this change (which was not): > > *) mod_dav: When a PROPPATCH attempts to remove a non-existent dead > property on a resource for which there is no dead property in the same > namespace httpd segfaults. PR 52559 [Diego Santa Cruz > ] > > What happens when someone commits a fix for something like this without > considering the possible security implications? Is someone going to > immediately update the log message to point out the security impact? > The security team should decide what to do about unintended partial disclosure on a case by case basis. I would guess in this case that the CHANGES entry should have been updated as soon as a CVE number was assigned since it is pretty obvious from the description that there is a remote exploit. > > Given that the issues are usually relatively minor and that they've usually > existed for a long time I'm not sure that the level of effort such a change > would constitute a positive change. I'm all for keeping things as > confidential > as can be done, but I don't think that you can make a policy decision like > this > without considering all the support for the decision. > > If we can't resolve some of these issues, the policy may have a negative > effect > on the security of our users. I suspect there are very few people > interested > in monitoring all our commits for security issues. The signal to noise > ratio > is too low to justify it. > > However, once you start including CVE numbers in every issue immediately > upon > commit then it will be very easy to monitor for these issues. That > creates the > opportunity for exploitation that may not have existed before. > 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. > As such I don't think given what discussion has gone on so far that I'm > comfortable voting for the mandatory option. I could be convinced to vote > for > it with the effort to make the decisions necessary to support it. But > based on > the votes cast so far I guess my vote really won't matter. So consider > this > email as asking how you plan to implement your policy. > 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. 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. -- Born in Roswell... married an alien... http://emptyhammock.com/ --089e01184bbaa3aad404efeff034 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 14, 2014 at 1:10 AM, Ben Reser <ben@reser.org> wrote:
On 1/11/14, 5:02 AM, Jeff Trawick wrote:
> I think a lot of your concerns revolve around assessment of when a
> vulnerability can be disclosed, and that has to be determined on a cas= e by case
> basis. =A0The vote is just about whether there will be an in-between s= ituation
> where we share some information we have (the code change) without shar= ing the
> rest, vs. deciding that, separate from the timing of how we release in= formation
> about a vulnerability, we either release all we have (code + impact) o= r none of it.

I guess my point is that there is a lot of process involved in not ha= ving that
in-between situation. =A0The vast majority of the situations do not present= a
critical threat. =A0It's a serious effort to take on that task.

How do you see the release process working if you delay committing code unt= il
we're ready to announce the vulnerability?

Are security advisories going to be separated from releases?

Will the advisories include patches for released versions? =A0If so does th= at
constitute a release and require a vote? =A0If so how does that vote take p= lace?

If we're not putting out advisories when the code is committed, how do = we
expect users to know about the fixes?

If we're not putting out releases with the advisories: For users that a= re
dependent on only using released version (binary packages that don't pa= tch,
have policies against patching, etc...) are we committed to limiting the ti= me
between that code commit/advisory and a release version? =A0Are we committe= d to
releasing all supported versions at roughly the same time? =A0Are we not concerned that we're increasing the time frame that these users receive= the
fixes since there is now a gap between us describing the vulnerability and = the
release being available to package.

The= simple answer to all of this is "look how httpd releases with securit= y fixes have been handled in the past." =A0The RM commits the fixes ju= st before Tag & Roll and, depending on the impact of the vulnerabilitie= s, may call for an abbreviated testing schedule.
=A0

I know there are fixes that impact security that slip through the gaps.
Compare this change (which was handled as a security issue):
=A0 *) SECURITY: CVE-2013-1896 (cve.mitre.org)
=A0 =A0 =A0mod_dav: Sending a MERGE request against a URI handled by mod_da= v_svn with
=A0 =A0 =A0the source href (sent as part of the request body as XML) pointi= ng to a
=A0 =A0 =A0URI that is not configured for DAV will trigger a segfault. [Ben= Reser
=A0 =A0 =A0<ben reser.org= >]

vs this change (which was not):

=A0 *) mod_dav: When a PROPPATCH attempts to remove a non-existent dead
=A0 =A0 =A0property on a resource for which there is no dead property in th= e same
=A0 =A0 =A0namespace httpd segfaults. PR 52559 [Diego Santa Cruz
=A0 =A0 =A0<diego.santaCruz spinetix.com>]

What happens when someone commits a fix for something like this without
considering the possible security implications? =A0Is someone going to
immediately update the log message to point out the security impact?

The security team should decide what to do ab= out unintended partial disclosure on a case by case basis. =A0I would guess= in this case that the CHANGES entry should have been updated as soon as a = CVE number was assigned since it is pretty obvious from the description tha= t there is a remote exploit.
=A0

Given that the issues are usually relatively minor and that they've usu= ally
existed for a long time I'm not sure that the level of effort such a ch= ange
would constitute a positive change. =A0I'm all for keeping things as co= nfidential
as can be done, but I don't think that you can make a policy decision l= ike this
without considering all the support for the decision.

If we can't resolve some of these issues, the policy may have a negativ= e effect
on the security of our users. =A0I suspect there are very few people intere= sted
in monitoring all our commits for security issues. =A0The signal to noise r= atio
is too low to justify it.

However, once you start including CVE numbers in every issue immediately up= on
commit then it will be very easy to monitor for these issues. =A0That creat= es the
opportunity for exploitation that may not have existed before.

This is back to choice 1 or choice 2, and whether o= r not you think that showing the code gives a would-be attacker useful info= rmation.



As such I don't think given what discussion has gone on so far that I&#= 39;m
comfortable voting for the mandatory option. =A0I could be convinced to vot= e for
it with the effort to make the decisions necessary to support it. =A0But ba= sed on
the votes cast so far I guess my vote really won't matter. =A0So consid= er this
email as asking how you plan to implement your policy.

The vote is about reaffirming support for and docume= nting a long-standing practice around commit/disclosure which has been foll= owed 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.

For this sm= all aspect of the overall policy that is being voted on, implementation is = as simple as having the security team determine whether or not a vulnerabil= ity can be fully disclosed prior to the time a release is prepared. =A0If i= t can, commit away. =A0If not, wait for Tag&Roll.


--
Born in = Roswell... married an alien...
http://emptyhammock.com/
--089e01184bbaa3aad404efeff034--