You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2014/01/10 14:38:51 UTC
[VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Open source projects, ASF or otherwise, have varying procedures for commits
of fixes to vulnerabilities. One important aspect of these procedures is
whether or not fixes to vulnerabilities can be committed to a repository
with commit logs and possibly CHANGES entries which purposefully obscure
the vulnerability and omit any available vulnerability tracking information.
(The vulnerabilities I refer to are those which are not already announced
or otherwise generally known to the user community, and where the would-be
committer knows that a vulnerability is fixed by the code change possibly
being committed. Often it will have been discussed previously with fellow
httpd developers in a private forum.)
[ ] It is an accepted practice (but not required) to obscure or omit the
vulnerability impact in CHANGES or commit log information when committing
fixes for vulnerabilities to any branch.
[ ] It is mandatory to provide best available description and any available
tracking information when committing fixes for vulnerabilities to any
branch, delaying committing of the fix if the information shouldn't be
provided yet.
[ ] _______________ (fill in the blank)
---/---
Obscuring details about a code change (the first choice above) presumably
wouldn't be done for a very obvious and high severity vulnerability. I
think that the possible justification for following the first choice for a
particular fix is that the committer feels that the vulnerability isn't
severe enough to completely hide it but it is severe enough that the
vulnerability impact shouldn't be publicized until there is a proposed
release with the fix which is being tested.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Marion & Christophe JAILLET <ch...@wanadoo.fr>.
Le 10/01/2014 14:38, Jeff Trawick a écrit :
> [ ] It is an accepted practice (but not required) to obscure or omit
> the vulnerability impact in CHANGES or commit log information when
> committing fixes for vulnerabilities to any branch.
>
> [X] It is mandatory to provide best available description and any
> available tracking information when committing fixes for
> vulnerabilities to any branch, delaying committing of the fix if the
> information shouldn't be provided yet.
>
> [ ] _______________ (fill in the blank)
>
> ---/---
>
Could be also interesting to be able to deliver quick fix.
For example, 2.4.7 is the latest stable version. 2.4.8 has things
back-ported from trunk little by little and should be T&R "one day" (in
feb ?).
Should an important vulnerability be found, then releasing:
- a 2.4.7.1 or
- 2.4.7 SP1 or
- 2.4.8 and delaying everything already accepted in backport for a
later 2.4.9 or
- whatever else
with *only fixes* for this issue, could be interesting.
Doing so would avoid time for T&R and avoid releasing something in a hurry.
Best regards,
CJ
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Rainer Jung <ra...@kippdata.de>.
On 11.01.2014 14:02, Jeff Trawick wrote:
> On Sat, Jan 11, 2014 at 2:51 AM, Ben Reser <ben@reser.org
> <ma...@reser.org>> wrote:
>
> On 1/10/14, 5:38 AM, Jeff Trawick wrote:
> > [ ] It is an accepted practice (but not required) to obscure or
> omit the
> > vulnerability impact in CHANGES or commit log information when
> committing fixes
> > for vulnerabilities to any branch.
> >
> > [X] It is mandatory to provide best available description and any
> available
> > tracking information when committing fixes for vulnerabilities to
> any branch,
> > delaying committing of the fix if the information shouldn't be
> provided yet.
> >
> > [ ] _______________ (fill in the blank)
Rainer
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Jan 14, 2014 at 12:56 PM, Ben Reser <be...@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." 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/
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Ben Reser <be...@reser.org>.
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.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Jan 14, 2014 at 1:10 AM, Ben Reser <be...@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 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
> <ben reser.org>]
>
> 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 spinetix.com>]
>
> 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/
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Ben Reser <be...@reser.org>.
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.
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
<ben reser.org>]
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 spinetix.com>]
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?
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.
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.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jan 11, 2014 at 2:51 AM, Ben Reser <be...@reser.org> wrote:
> On 1/10/14, 5:38 AM, Jeff Trawick wrote:
> > [ ] It is an accepted practice (but not required) to obscure or omit the
> > vulnerability impact in CHANGES or commit log information when
> committing fixes
> > for vulnerabilities to any branch.
> >
> > [ ] It is mandatory to provide best available description and any
> available
> > tracking information when committing fixes for vulnerabilities to any
> branch,
> > delaying committing of the fix if the information shouldn't be provided
> yet.
> >
> > [ ] _______________ (fill in the blank)
>
> The Subversion project has struggled with this same issue. To the degree
> that
> there has actually been a fair amount of thought into how to avoid doing
> security by obscurity.
>
> The processes we've discussed have varied from executing the release
> entirely
> hidden from anyone but the PMC to simply publishing an advisory with a
> patch
> right before committing to trunk (treating that advisory with patch as a
> release with appropriate voting handled by PMC members privately).
>
> You're always dealing with a certain amount of security by obscurity. The
> bugs
> we find often have existed for a long time. If one person can find it
> someone
> else certainly could. For all we know the issues may have already been
> found
> and only exploited in limited ways such that the issue was never reported.
>
> Even with advance notification I've found that the binary packagers can
> take
> their sweet time getting security fixes included. Some binary packagers
> don't
> really have a process that supports patching (they release one package for
> each
> version without a method of identify versions that have been patched).
> Administrators may not always know what to do with patches. So frankly
> all of
> the processes stink.
>
> Yet, I think that the best process is to reveal security issues when you
> can
> put your best foot forward and have things positioned to get the fixes in
> the
> hands of as many users as possible as quickly as possible. I think that's
> best
> served by withholding details (even if you're doing so imperfectly) until
> release or the issue is widely disclosed to the public.
>
> It should be noted that not all security issues are equal. For the most
> part
> highly critical fixes are rare, when they do come up we could use a release
> process that hides everything from non-PMC members until release time
> frame.
> With other less severe issues possibly just disclosing immediately when we
> apply the fix.
>
> There doesn't need to be a one size fits all answer to this. But I
> certainly
> would like to see us have a consistent policy for determining which
> process to
> follow.
>
> So my vote wouldn't really fit into the options presented above. I'd
> suggest
> coming up with a process for varying levels of issues and criteria to
> determine
> which process to follow.
>
Hmmm... Maybe I'm missing part of your point, but I think that there is
acknowledgement of different issue severities in the vote. The crucial
part of the second choice is a simple division of vulnerabilities into two
groups by severity:
a) low enough severity to share information when tag & roll is not imminent
(and furthermore share *all* information)
b) high enough severity to NOT share information when tag & roll is not
imminent (and furthermore share *no* information)
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.
Apologies in advance for what I worry is a crude summary of your thoughts :)
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Ben Reser <be...@reser.org>.
On 1/10/14, 5:38 AM, Jeff Trawick wrote:
> [ ] It is an accepted practice (but not required) to obscure or omit the
> vulnerability impact in CHANGES or commit log information when committing fixes
> for vulnerabilities to any branch.
>
> [ ] It is mandatory to provide best available description and any available
> tracking information when committing fixes for vulnerabilities to any branch,
> delaying committing of the fix if the information shouldn't be provided yet.
>
> [ ] _______________ (fill in the blank)
The Subversion project has struggled with this same issue. To the degree that
there has actually been a fair amount of thought into how to avoid doing
security by obscurity.
The processes we've discussed have varied from executing the release entirely
hidden from anyone but the PMC to simply publishing an advisory with a patch
right before committing to trunk (treating that advisory with patch as a
release with appropriate voting handled by PMC members privately).
You're always dealing with a certain amount of security by obscurity. The bugs
we find often have existed for a long time. If one person can find it someone
else certainly could. For all we know the issues may have already been found
and only exploited in limited ways such that the issue was never reported.
Even with advance notification I've found that the binary packagers can take
their sweet time getting security fixes included. Some binary packagers don't
really have a process that supports patching (they release one package for each
version without a method of identify versions that have been patched).
Administrators may not always know what to do with patches. So frankly all of
the processes stink.
Yet, I think that the best process is to reveal security issues when you can
put your best foot forward and have things positioned to get the fixes in the
hands of as many users as possible as quickly as possible. I think that's best
served by withholding details (even if you're doing so imperfectly) until
release or the issue is widely disclosed to the public.
It should be noted that not all security issues are equal. For the most part
highly critical fixes are rare, when they do come up we could use a release
process that hides everything from non-PMC members until release time frame.
With other less severe issues possibly just disclosing immediately when we
apply the fix.
There doesn't need to be a one size fits all answer to this. But I certainly
would like to see us have a consistent policy for determining which process to
follow.
So my vote wouldn't really fit into the options presented above. I'd suggest
coming up with a process for varying levels of issues and criteria to determine
which process to follow.
AW: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to
vulnerabilities
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
Von: Jeff Trawick [mailto:trawick@gmail.com]
Gesendet: Freitag, 10. Januar 2014 14:39
An: Apache HTTP Server Development List
Betreff: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Open source projects, ASF or otherwise, have varying procedures for commits of fixes to vulnerabilities. One important aspect of these procedures is whether or not fixes to vulnerabilities can be committed to a repository with commit logs and possibly CHANGES entries which purposefully obscure the vulnerability and omit any available vulnerability tracking information.
(The vulnerabilities I refer to are those which are not already announced or otherwise generally known to the user community, and where the would-be committer knows that a vulnerability is fixed by the code change possibly being committed. Often it will have been discussed previously with fellow httpd developers in a private forum.)
[ ] It is an accepted practice (but not required) to obscure or omit the vulnerability impact in CHANGES or commit log information when committing fixes for vulnerabilities to any branch.
[ X ] It is mandatory to provide best available description and any available tracking information when committing fixes for vulnerabilities to any branch, delaying committing of the fix if the information shouldn't be provided yet.
[ ] _______________ (fill in the blank)
---/---
Obscuring details about a code change (the first choice above) presumably wouldn't be done for a very obvious and high severity vulnerability. I think that the possible justification for following the first choice for a particular fix is that the committer feels that the vulnerability isn't severe enough to completely hide it but it is severe enough that the vulnerability impact shouldn't be publicized until there is a proposed release with the fix which is being tested.
Regards
Rüdiger
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to
vulnerabilities
Posted by Noel Butler <no...@ausics.net>.
On Fri, 2014-01-10 at 08:38 -0500, Jeff Trawick wrote:
>
>
> [ X] It is mandatory to provide best available description and any
> available tracking information when committing fixes for
> vulnerabilities to any branch, delaying committing of the fix if the
> information shouldn't be provided yet.
>
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to
vulnerabilities
Posted by Joe Orton <jo...@redhat.com>.
> [X] It is mandatory to provide best available description and any available
> tracking information when committing fixes for vulnerabilities to any
> branch, delaying committing of the fix if the information shouldn't be
> provided yet.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Stefan Fritsch <sf...@sfritsch.de>.
Am Freitag, 10. Januar 2014, 08:38:51 schrieb Jeff Trawick:
> [X] It is mandatory to provide best available description and any
> available tracking information when committing fixes for
> vulnerabilities to any branch, delaying committing of the fix if
> the information shouldn't be provided yet.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Jan 12, 2014 at 10:23 AM, Tim Bannister <is...@jellybaby.net> wrote:
> On 12 Jan 2014, at 13:33, Jeff Trawick wrote:
>
> > On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <tr...@gmail.com> wrote:
> > Open source projects, ASF or otherwise, have varying procedures for
> commits of fixes to vulnerabilities. ...
> >
> > I plan to update http://httpd.apache.org/dev/guidelines.html based on
> the outcome of the vote.
> >
> > Folks, if you want to express an opinion but haven't yet, please do so
> before Tuesday.
> >
> > I'll add something very close to the following, unless the vote changes
> considerably:
> >
> > ---cut here---
> > Open source projects, ASF or otherwise, have varying procedures for
> commits of vulnerability fixes. One important aspect of these procedures
> is whether or not fixes to vulnerabilities can be committed to a repository
> with commit logs and possibly CHANGES entries which purposefully obscure
> the vulnerability and omit any available vulnerability tracking
> information. The Apache HTTP Server project has decided that it is in the
> best interest of our users that the initial commit of such code changes to
> any branch will provide the best description available at that time as well
> as any available tracking information such as CVE number when committing
> fixes for vulnerabilities to any branch. Committing of the fix will be
> delayed until the project determines that all of the information about the
> issue can be shared.
> >
> > In some cases there are very real benefits to sharing code early even if
> full information about the issue cannot, including the potential for
> broader review, testing, and distribution of the fix. This is outweighed by
> the concern that sharing only the code changes allows skilled analysts to
> determine the impact and exploit mechanisms but does not allow the general
> user community to determine if preventative measures should be taken.
> > ---cut here---
>
> s/outweighed by/balanced against/ ?
>
>
"balanced against" sounds fancier but I think we're deciding that it is
more "imbalanced" than "balanced"
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Tim Bannister <is...@jellybaby.net>.
On 12 Jan 2014, at 13:33, Jeff Trawick wrote:
> On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <tr...@gmail.com> wrote:
> Open source projects, ASF or otherwise, have varying procedures for commits of fixes to vulnerabilities. ...
>
> I plan to update http://httpd.apache.org/dev/guidelines.html based on the outcome of the vote.
>
> Folks, if you want to express an opinion but haven't yet, please do so before Tuesday.
>
> I'll add something very close to the following, unless the vote changes considerably:
>
> ---cut here---
> Open source projects, ASF or otherwise, have varying procedures for commits of vulnerability fixes. One important aspect of these procedures is whether or not fixes to vulnerabilities can be committed to a repository with commit logs and possibly CHANGES entries which purposefully obscure the vulnerability and omit any available vulnerability tracking information. The Apache HTTP Server project has decided that it is in the best interest of our users that the initial commit of such code changes to any branch will provide the best description available at that time as well as any available tracking information such as CVE number when committing fixes for vulnerabilities to any branch. Committing of the fix will be delayed until the project determines that all of the information about the issue can be shared.
>
> In some cases there are very real benefits to sharing code early even if full information about the issue cannot, including the potential for broader review, testing, and distribution of the fix. This is outweighed by the concern that sharing only the code changes allows skilled analysts to determine the impact and exploit mechanisms but does not allow the general user community to determine if preventative measures should be taken.
> ---cut here---
s/outweighed by/balanced against/ ?
--
Tim Bannister – isoma@jellybaby.net
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Eric Covener <co...@gmail.com>.
On Sun, Jan 12, 2014 at 8:33 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>> Open source projects, ASF or otherwise, have varying procedures for
>> commits of fixes to vulnerabilities. ...
>
>
> I plan to update http://httpd.apache.org/dev/guidelines.html based on the
> outcome of the vote.
>
> Folks, if you want to express an opinion but haven't yet, please do so
> before Tuesday.
Not opinionated on this one and going with the consensus.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 10, 2014 at 8:38 AM, Jeff Trawick <tr...@gmail.com> wrote:
> Open source projects, ASF or otherwise, have varying procedures for
> commits of fixes to vulnerabilities. ...
>
I plan to update http://httpd.apache.org/dev/guidelines.html based on the
outcome of the vote.
Folks, if you want to express an opinion but haven't yet, please do so
before Tuesday.
I'll add something very close to the following, unless the vote changes
considerably:
---cut here---
Open source projects, ASF or otherwise, have varying procedures for commits
of vulnerability fixes. One important aspect of these procedures is
whether or not fixes to vulnerabilities can be committed to a repository
with commit logs and possibly CHANGES entries which purposefully obscure
the vulnerability and omit any available vulnerability tracking
information. The Apache HTTP Server project has decided that it is in the
best interest of our users that the initial commit of such code changes to
any branch will provide the best description available at that time as well
as any available tracking information such as CVE number when committing
fixes for vulnerabilities to any branch. Committing of the fix will be
delayed until the project determines that all of the information about the
issue can be shared.
In some cases there are very real benefits to sharing code early even if
full information about the issue cannot, including the potential for
broader review, testing, and distribution of the fix. This is outweighed by
the concern that sharing only the code changes allows skilled analysts to
determine the impact and exploit mechanisms but does not allow the general
user community to determine if preventative measures should be taken.
---cut here---
> One important aspect of these procedures is whether or not fixes to
> vulnerabilities can be committed to a repository with commit logs and
> possibly CHANGES entries which purposefully obscure the vulnerability and
> omit any available vulnerability tracking information.
>
> (The vulnerabilities I refer to are those which are not already announced
> or otherwise generally known to the user community, and where the would-be
> committer knows that a vulnerability is fixed by the code change possibly
> being committed. Often it will have been discussed previously with fellow
> httpd developers in a private forum.)
>
> [ ] It is an accepted practice (but not required) to obscure or omit the
> vulnerability impact in CHANGES or commit log information when committing
> fixes for vulnerabilities to any branch.
>
> [ ] It is mandatory to provide best available description and any
> available tracking information when committing fixes for vulnerabilities to
> any branch, delaying committing of the fix if the information shouldn't be
> provided yet.
>
> [ ] _______________ (fill in the blank)
>
> ---/---
>
> Obscuring details about a code change (the first choice above) presumably
> wouldn't be done for a very obvious and high severity vulnerability. I
> think that the possible justification for following the first choice for a
> particular fix is that the committer feels that the vulnerability isn't
> severe enough to completely hide it but it is severe enough that the
> vulnerability impact shouldn't be publicized until there is a proposed
> release with the fix which is being tested.
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Reindl Harald <h....@thelounge.net>.
+1
in some cases re-consider if a used option is really needed
and disable it may close a vulnerability, the admin only
needs to know that there is danger
Am 10.01.2014 15:24, schrieb Jim Jagielski:
> +1
> On Jan 10, 2014, at 8:44 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> [X] It is mandatory to provide best available description and any available tracking information when committing fixes for vulnerabilities to any branch, delaying committing of the fix if the information shouldn't be provided yet.
>>
>> --/--
>>
>> IMO it is not appropriate to let skilled attackers see a code change (which they can analyze to determine if there is an impact that they can exploit) if you are not going to make it possible for the general user community looking at the same commit activity to decide if they need to take an action.
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
On Jan 10, 2014, at 8:44 AM, Jeff Trawick <tr...@gmail.com> wrote:
> [X] It is mandatory to provide best available description and any available tracking information when committing fixes for vulnerabilities to any branch, delaying committing of the fix if the information shouldn't be provided yet.
>
> --/--
>
> IMO it is not appropriate to let skilled attackers see a code change (which they can analyze to determine if there is an impact that they can exploit) if you are not going to make it possible for the general user community looking at the same commit activity to decide if they need to take an action.
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
Re: [VOTE] obscuring (or not) commit logs/CHANGES for fixes to vulnerabilities
Posted by Jeff Trawick <tr...@gmail.com>.
[X] It is mandatory to provide best available description and any available
tracking information when committing fixes for vulnerabilities to any
branch, delaying committing of the fix if the information shouldn't be
provided yet.
--/--
IMO it is not appropriate to let skilled attackers see a code change (which
they can analyze to determine if there is an impact that they can exploit)
if you are not going to make it possible for the general user community
looking at the same commit activity to decide if they need to take an
action.
--
Born in Roswell... married an alien...
http://emptyhammock.com/