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 19:06:01 GMT
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

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

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

Born in Roswell... married an alien...

View raw message