[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Earlier embargoed pre-disclosure without patches



> On 26 May 2015, at 17:34, Stefano Stabellini 
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> 
>> Thanks for the help, folks.  I've tossed a proposed security policy change 
>> into a Github gist[1].
>> 
>> My proposal is to add this paragraph to the "Embargo and disclosure 
>> schedule" section of the Xen Security Policy[2]:
>> 
>>    In the event that a two week embargo cannot be guaranteed,
>>    we will send a draft with information about the vulnerability
>>    to the pre-disclosure list as soon as possible, even if 
>>    patches have not yet been written or tested.  An updated 
>>    draft will be sent to the pre-disclosure list once patches
>>    become available.
>> 
>> I welcome any and all feedback.  Thanks!
> 
> I would go for:
> 
> In the event that public disclosure is less than 15 days away, we will
> send a draft with information about the vulnerability to the
> pre-disclosure list as soon as possible, even if patches have not yet
> been written or tested.  An updated draft will be sent to the
> pre-disclosure list once patches become available.

I think the wording can be tightened.

There appear to be two sections which are relevant in 
http://www.xenproject.org/security-policy.html

---
== Embargo and disclosure schedule ==

If a vulnerability is not already public, we would like to notify significant 
distributors and operators of Xen so that they can prepare patched software in 
advance. This will help minimise the degree to which there are Xen users who 
are vulnerable but can't get patches. 

As discussed, we will negotiate with discoverers about disclosure schedule. Our 
usual starting point for that negotiation, unless there are reasons to diverge 
from this, would be: 

1. One working week between notification arriving at security@xenproject and 
the issue of our own advisory to our predisclosure list. We will use this time 
to gather information and prepare our advisory, including required patches. 

2. Two working weeks between issue of our advisory to our predisclosure list 
and publication. When a discoverer reports a problem to us and requests longer 
delays than we would consider ideal, we will honour such a request if 
reasonable. 

If a discoverer wants an accelerated disclosure compared to what we would 
prefer, we naturally do not have the power to insist that a discoverer waits 
for us to be ready and will honour the date specified by the discoverer. 

Naturally, if a vulnerability is being exploited in the wild we will make 
immediately public release of the advisory and patch(es) and expect others to 
do likewise.

...

== Specific process ==
...
4. Advisory pre-release: 

This occurs only if the advisory is embargoed (ie, the problem is not already 
public): 

As soon as our advisory is available, we will send it, including patches, to 
members of the Xen security pre-disclosure list. 

For more information about this list, see below. At this stage the advisory 
will be clearly marked with the embargo date.
...
6. Updates 

If new information or better patches become available, or we discover mistakes, 
we may issue an amended (revision 2 or later) public advisory. This will also 
be sent to the pre-disclosure list.
...
---

I would want to propose to word the suggestion differently. Firstly: "An 
updated draft will be sent to the pre-disclosure list once patches become 
available." is already covered by 6 and not necessary. I would also like to 
propose to stick with "two working weeks" for consistency reasons. 

The following change should suffice IMHO
---
== Specific process ==
...
4. Advisory pre-release: 

This occurs only if the advisory is embargoed (ie, the problem is not already 
public): 

As soon as our advisory is available, we will send it, including patches, to 
members of the Xen security pre-disclosure list. 

In the event that we do not have a patch available two working weeks before the 
disclosure date, we will aim to send a draft of the advisory to the Xen 
security pre-disclosure list instead of a full advisory, and publish an updated 
advisory as soon as available. 
---

Somebody may have to go over the new paragraph and fix grammar issues (sorry: 
very tired from long plane ride). We also have options: replace "will aim to" 
with "may"

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.