Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

On 8 Oct 2014, at 16:06, Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Xen Project Security Team writes ("Security policy ambiguities - XSA-108 
> process post-mortem"):
>> We welcome any feedback on our decisions and we look forward to
>> clearer directions from the community.
> 
> Here is my own, purely personal, response with answers to the
> questions asked.  NB that this is not the opinion of Citrix nor of
> the Xen Project Security Team.  But I thought I would at least write
> down something concrete for people to argue about.
> 
> 
>> Sharing amongst predisclosure list members
> 
> I think that the answer should be `yes', in principle.  There seems
> little point forbidding this.
> 
> Allowing greater sharing would perhaps allow problems with patches to
> be discovered (and the revised patches developed) more easily.  We
> should provide a clear channel for collaboration between predisclosure
> list members.
> 
> Therefore, the policy should be extended by adding, before
> `Organisations who meet the criteria', the new section:
> 
>  List members are allowed to share fixes to embargoed issues,
>  analysis, etc., with the security teams of other list members.
>  Technical measures must be taken to prevents non-list-member
>  organisations, or unauthorised staff in list-member organisations,
>  from obtaining the embargoed materials.
> 
>  The Xen Project provides the mailing list
>     xen-security-issues-discuss@xxxxxxxxxxxxxxxxxxxx
>  for this purpose.  List members are encouraged to use it but
>  may share with other list members' security teams via other
>  channels.
> 
>  The -discuss list's distribution is identical to that of the primary
>  predisclosure list xen-security-issues.  Recipient organisations who
>  do not wish to receive all of the traffic on -discuss should use
>  recipient-side email filtering based on the provided `List-Id'.
> 
>  The -discuss list is moderated by the Xen Project Security Team.
>  Announcements of private availability of fixed versions, and
>  technical messages about embargoed advisories, will be approved.
>  Messages dealing with policy matters will be rejected with a
>  reference to the Security Team contact address and/or public Xen
>  mailing lists.
> 
> (That list obviously doesn't exist yet, but if the policy is approved
> we will create it.)

Ian, this is a very good suggestion. 

> 
> One reason for permitting this is that we want fairness between
> service providers who use their own versions of Xen, and ones who use
> a version from a software provider.  Both kinds of service provider
> should be able to test the fix during the embargo.
> 
> 
>> Deployment on public systems of fixed versions during embargo
> 
> These different understandings have led to some bad feelings - some
> people feel that others have breached the embargo, while they felt
> prevented from acting similarly.  This is very regrettable and I
> apologise for my contribution to the unclarity in the policy.
> 
> I want to say clearly that I think everyone has acted in good faith.
> 
> My view is that the policy should be clarified to permit deployment
> during embargo.  I see no practical reason for preventing it.  

I agree. If we didn’t allow deployment during an embargo a lot more users would 
be at risk.

However, in this context we do need to look at a number of questions:
a) Risk of someone reverse engineering the vulnerability during deployment. 
b) GPL (or license) compliance - this may be a non-issue, but I would like to 
get some advice on it. 

In the case of XSA 108 both were not an issue, because the hypervisor is not 
accessible by a user of a cloud provider.
However, if the vulnerability had been in another component this may be 
different.


> I would
> add, following that list of bullet points:
> 
>  List members who are service providers may deploy fixed versions
>  during the embargo, PROVIDED THAT any action taken by the service
>  provider gives no indication (to their users or anyone else) as to
>  the nature of the vulnerability.

I think this does text does not address a) and b)

> 
> This question is IMO partly linked to the previous one.
> 
> 
> The Security Team should not be invited to give permission
> specifically for the release of patched software.  I think the rider
> was mistakenly merged into the final the bullet point in the list.  It
> should be separated out.  Also, the predisclosure list members should
> not be invited to consult the discoverer.
> 
> The note about CVE numbers should be moved into the list of
> forbidden-disclosures, as a new bullet point.  So overall I would
> delete that whole paragraph about CVEs (we don't need the historical
> information) and adjust the end of the forbidden disclosures to read:
> 
>    ...
>    * patched software (even in binary form)
>    * CVE number(s)
> 
>  without prior consultation with security@xenproject.
> 
> 
>> Service announcements to non-list-member users during embargo
> 
> We should add just below the list of bullet points of things which may
> be disclosed:
> 
>  Where the list member is a service provider who intends to take
>  disruptive action such as rebooting as part of deploying a fix (see
>  above): the list member's communications to its users about the
>  service disruption may mention that the disruption is to correct a
>  security issue, and relate it to the public information about the
>  issue (as listed above).
> 
> 
>> Predisclosure list memembership
> 
> The policy should be amended to require applicants to provide the
> information required, in the form of public URLs.  The team should not
> be required to judge email aliases or enquire about their recipients
> except to ensure that they don't look like personal aliases.
> 
> Applicants should be required to:
> 
>  - Provide information on their public web pages which makes
>    it clear that and why they are eligible;
> 
>  - Specifically, publicly state that and how they are using Xen
>    (so that the Security Team can verify eligibility);
> 
>  - Provide a way for members of the public to responsibly report
>    security problems to the applicant, just as the Xen Project does.
> 
> The Security Team should be forbidden from trying to hunt down
> eligibility information etc. and should instead be mandated to reject
> incomplete requests.
> 
> 
> Specifically, I propose that the section on list membership
> applications be entirely replaced with this:
> 
>  Organisations who meet the criteria should contact
>  security@xenproject if they wish to receive pre-disclosure of
>  advisories.  You must include in the e-mail:
> 
>    * The name of your organization.
> 
>    * Domain name(s) which you use to provide Xen software/services.
> 
>    * A brief description of why you fit the criteria.
> 
>    * If not all of your products/services use Xen, a list of (some
>      of) your products/services (or categories thereof) which do.
> 
>    * Link(s) to current public web pages, belonging to your
>      organisation, for each of following pieces of information:
> 
>      o Evidence of your status as a service/software provider:
>        + If you are a public hosting provider, your public rates
>          or how to get a quote
>        + If you are a software provider, how your
>          software can be downloaded or purchased
>        + If you are an open-source project, a mailing list
>          archive and/or version control repository, with
>          active development
> 
>      o Evidence of your status as a user of Xen:
>        + Statements about, or descriptions of, your eligible
>          production services or released software, from which it is
>          immediately evident that they use Xen.
> 
>      o Information about your handling of security problems:
>        + Your invitation to members of the public, who discover
>          security problems with your products/services, to report
>          them in confidence to you;
>        + Specifically, the contact information (email addresses or
>          other contact instructions) which such a member of the
>          public should use.
> 
>      Blog postings, conference presentations, social media pages,
>      Flash presentations, videos, sites which require registration,
>      anything password-protected, etc., are not acceptable.  PDFs of
>      reasonable size are acceptable so long as the URL you provide is
>      of a ordinary HTML page providing a link to the PDF.
> 
>      If the pages are long and/or PDFs are involved, your email
>      should say which part of the pages and documents are relevant.
> 
>    * A statement to the effect that you have read this policy and
>      agree to abide by the terms for inclusion in the list,
>      specifically the requirements regarding confidentiality during
>      an embargo period.
> 
>    * The single (non-personal) email alias you wish added to the
>      predisclosure list.
> 
>  The Security Team has no discretion to accept applications which do
>  not provide all of the information required above.

This is a good list.
I do think we should test this though to make sure it actually works. I think 
there are a few areas which may be ambiguous or not clear enough.

I also think we do need to address websites in non-english languages would be 
handled. Of course we do not want to discriminate. 

> 
>  Please provide URLs which are accessible and legible on mobile phone
>  browsers, which do not require cookies enabled to load, and which
>  are useable with text mode browsers, browsers which do not execute
>  Javascript, and with screen readers and other accessibility
>  software.  If the member of the Xen Project Security Team who
>  processes your application finds that their usual web browser does
>  not display the required information, when presented with the URLs
>  in your email, your application might be delayed or even rejected.
> 
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel


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