Changing the httpd security process

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing the httpd security process

Joe Orton
At the moment we follow the standard ASF process for handling security
vulnerabilities, https://www.apache.org/security/committers.html

This includes the following step where fixes are committed with
"obscured" commit messages prior to release:

"12. The project team commits the fix. No reference should be made to the
commit being related to a security vulnerability."

I find this deeply distateful, and poor practice, for three reasons:

a) it requires committers to lie (either by omission, or explicitly)
when describing changes in the source code history.  If there were an
extremely good justification for lying, say, fixing an embargoed
Critical vulnerability which affects millions of servers, I could live
with it.  But we apply this for everything, even trivial Low-severity
vulnerabilities.

b) it creates a nasty conflict for mod_h2, where Stefan is cutting
mod_h2 releases at github which he knows address vulnerabilities, but is
unable to disclose that until the time of an httpd release.  So mod_h2
users have access to releases which fix undisclosed vulnerabilities for
sometimes months prior to an httpd release, but aren't given the true
information on why/whether they need to upgrade.

c) because our mirrored git history is immutable, svn revision log
message changes - which retroactively add CVE names and make the svn log
a "true" record of history, rather than one containing deliberate lies,
never make it to the git log.

My preference is that we follow the ASF process for Critical
vulnerabilities, and for anything less than Critical we use a modified
version of the ASF policy, which has instead:

12. The project team commits the fix, referencing the assigned CVE, and
then:

 a. Notifies the reporter that the fix is public, and will be included
 in a future release.

 b. Notifies MITRE, etc etc as per 15. (e) in the ASF policy

13, 14, 15 as per ASF policy except for MITRE disclose being done earlier.

16 is now unnecessary.

This roughly reverts the httpd process to what we used prior to adopting
the Tomcat-esque policy for the whole ASF.  We would have to document
this and possibly need it approved by the ASF security team.

Thoughts?

Regards, Joe

Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Ruediger Pluem


On 8/17/20 1:08 PM, Joe Orton wrote:

> At the moment we follow the standard ASF process for handling security
> vulnerabilities, https://www.apache.org/security/committers.html
>
> This includes the following step where fixes are committed with
> "obscured" commit messages prior to release:
>
> "12. The project team commits the fix. No reference should be made to the
> commit being related to a security vulnerability."
>
> I find this deeply distateful, and poor practice, for three reasons:
>
> a) it requires committers to lie (either by omission, or explicitly)
> when describing changes in the source code history.  If there were an
> extremely good justification for lying, say, fixing an embargoed
> Critical vulnerability which affects millions of servers, I could live
> with it.  But we apply this for everything, even trivial Low-severity
> vulnerabilities.
>
> b) it creates a nasty conflict for mod_h2, where Stefan is cutting
> mod_h2 releases at github which he knows address vulnerabilities, but is
> unable to disclose that until the time of an httpd release.  So mod_h2
> users have access to releases which fix undisclosed vulnerabilities for
> sometimes months prior to an httpd release, but aren't given the true
> information on why/whether they need to upgrade.
>
> c) because our mirrored git history is immutable, svn revision log
> message changes - which retroactively add CVE names and make the svn log
> a "true" record of history, rather than one containing deliberate lies,
> never make it to the git log.
>
> My preference is that we follow the ASF process for Critical
> vulnerabilities, and for anything less than Critical we use a modified

It might be debatable if the ASF process should already apply for Important
vulnerabilities, but otherwise I agree.
I don't think that low or moderate security issues always require an immediate release to be done. Hence I think it would be fine
to just have the patches available. OTOH some of these patches might need tweaks before they could be backported e.g. due to merge
conflicts and hence it wouldn't be that easy for some users to apply them.
Maybe the workaround here is to work on these patches in /pmc/httpd/SECURITY/ first and keep stuff there until
a backport proposal has been voted on there such that we can commit to trunk and 2.4.x nearly at the same time with the "true"
commit message and people who don't want to wait for the release can pick up the patch from the 2.4.x branch and merge it
into their build.


> version of the ASF policy, which has instead:
>
> 12. The project team commits the fix, referencing the assigned CVE, and
> then:
>
>  a. Notifies the reporter that the fix is public, and will be included
>  in a future release.
>
>  b. Notifies MITRE, etc etc as per 15. (e) in the ASF policy
>
> 13, 14, 15 as per ASF policy except for MITRE disclose being done earlier.
>
> 16 is now unnecessary.
>
> This roughly reverts the httpd process to what we used prior to adopting
> the Tomcat-esque policy for the whole ASF.  We would have to document
> this and possibly need it approved by the ASF security team.

Not sure if we need to have it approved, but at least we should discuss with the ASF security team.

Regards

Rüdiger
Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Eric Covener
In reply to this post by Joe Orton
> This roughly reverts the httpd process to what we used prior to adopting
> the Tomcat-esque policy for the whole ASF.  We would have to document
> this and possibly need it approved by the ASF security team.

+1
Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Mark Cox
In reply to this post by Ruediger Pluem
> > This roughly reverts the httpd process to what we used prior to adopting
> > the Tomcat-esque policy for the whole ASF.  We would have to document
> > this and possibly need it approved by the ASF security team.
>
> Not sure if we need to have it approved, but at least we should discuss with the ASF security team.

https://s.apache.org/cveprocess allows projects to deviate from the default policy with "review" from the ASF security team.  So once you have agreement have the PMC present the proposed policy.  

This is not an uncommon plan, outside of ASF projects such as OpenSSL have similar policies where lower severity issues (low/moderate) are committed as security fixes prior to and independently of releases.  Dealing with security issues in private is a pain in both the process and getting the right fix with limited reviewers.  It's worth that pain when the issue is an actual risk to users, less so for the low risk issues.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Dan Ehrlich
Wait isn't Mark Cox the guy currently under investigation by MI5 for something something hacking on behalf of the Ministry of State Security for the PRC? Something to do with subverting encryption globally.

That's partially why Huawei donated so much to OpenSSL, they get the 0 days seven days in advance. Something to do with this:


"include the option of us giving prenotification to companies with which we have a commercial relationship"

Whitehurst and Cormier are aware of this as the American FBI talked to them last week. 



On Mon, Aug 17, 2020 at 8:06 AM Mark J. Cox <[hidden email]> wrote:
> > This roughly reverts the httpd process to what we used prior to adopting

> > the Tomcat-esque policy for the whole ASF.  We would have to document

> > this and possibly need it approved by the ASF security team.

>

> Not sure if we need to have it approved, but at least we should discuss with the ASF security team.



https://s.apache.org/cveprocess allows projects to deviate from the default policy with "review" from the ASF security team.  So once you have agreement have the PMC present the proposed policy. 



This is not an uncommon plan, outside of ASF projects such as OpenSSL have similar policies where lower severity issues (low/moderate) are committed as security fixes prior to and independently of releases.  Dealing with security issues in private is a pain in both the process and getting the right fix with limited reviewers.  It's worth that pain when the issue is an actual risk to users, less so for the low risk issues.



Mark

Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Jim Jagielski
In reply to this post by Joe Orton
++1. I was never quite happy with this process, but it seemed like there was a lot of support for this kind of treatment.

> On Aug 17, 2020, at 7:08 AM, Joe Orton <[hidden email]> wrote:
>
>
> This roughly reverts the httpd process to what we used prior to adopting
> the Tomcat-esque policy for the whole ASF.  We would have to document
> this and possibly need it approved by the ASF security team.
>

Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Joe Orton
In reply to this post by Joe Orton
On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote:
> This roughly reverts the httpd process to what we used prior to adopting
> the Tomcat-esque policy for the whole ASF.  We would have to document
> this and possibly need it approved by the ASF security team.

Thanks to those who have given feedback.

I won't rush this since it's Summer and people may be on holiday, if by
the start of September there is no dissent I will assume PMC consensus
for making this change and work out how to document & notify security@.

Regards, Joe

Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Stefan Eissing


> Am 20.08.2020 um 18:24 schrieb Joe Orton <[hidden email]>:
>
> On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote:
>> This roughly reverts the httpd process to what we used prior to adopting
>> the Tomcat-esque policy for the whole ASF.  We would have to document
>> this and possibly need it approved by the ASF security team.
>
> Thanks to those who have given feedback.
>
> I won't rush this since it's Summer and people may be on holiday, if by
> the start of September there is no dissent I will assume PMC consensus
> for making this change and work out how to document & notify security@.

+1

> Regards, Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Ruediger Pluem
In reply to this post by Joe Orton


On 8/20/20 6:24 PM, Joe Orton wrote:

> On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote:
>> This roughly reverts the httpd process to what we used prior to adopting
>> the Tomcat-esque policy for the whole ASF.  We would have to document
>> this and possibly need it approved by the ASF security team.
>
> Thanks to those who have given feedback.
>
> I won't rush this since it's Summer and people may be on holiday, if by
> the start of September there is no dissent I will assume PMC consensus
> for making this change and work out how to document & notify security@.
>

+1

Regards

Rüdiger
Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Sander Temme-2
In reply to this post by Joe Orton
+1

> On Aug 20, 2020, at 9:24 AM, Joe Orton <[hidden email]> wrote:
>
> On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote:
>> This roughly reverts the httpd process to what we used prior to adopting
>> the Tomcat-esque policy for the whole ASF.  We would have to document
>> this and possibly need it approved by the ASF security team.
>
> Thanks to those who have given feedback.
>
> I won't rush this since it's Summer and people may be on holiday, if by
> the start of September there is no dissent I will assume PMC consensus
> for making this change and work out how to document & notify security@.
>
> Regards, Joe
>

Reply | Threaded
Open this post in threaded view
|

Re: Changing the httpd security process

Christophe JAILLET
In reply to this post by Joe Orton

Le 20/08/2020 à 18:24, Joe Orton a écrit :

> On Mon, Aug 17, 2020 at 12:08:35PM +0100, Joe Orton wrote:
>> This roughly reverts the httpd process to what we used prior to adopting
>> the Tomcat-esque policy for the whole ASF.  We would have to document
>> this and possibly need it approved by the ASF security team.
> Thanks to those who have given feedback.
>
> I won't rush this since it's Summer and people may be on holiday, if by
> the start of September there is no dissent I will assume PMC consensus
> for making this change and work out how to document & notify security@.
>
> Regards, Joe
+1

CJ