httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Date Tue, 14 Jan 2014 15:35:20 GMT
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 (
>      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
>      <ben>]
> 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
>      <diego.santaCruz>]
> 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

> 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

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

View raw message