Xen devel - Jul 2011 - Security vulnerability process - last call

In May I sent out a draft security vulnerability process.  Mostly it
seems to have met with approval or at least acquiescence.

We received some comments and based on that I have prepared a new
final draft.  The changes ought not to be controversial.

Please send any final comments by the 28th of July (14 days from
now).  Unless there are objections, we will regard the process as
formally in force from that date.

Thanks,
Ian.


Changes from the previous draft:

  * The pre-disclosure list will get copies of public advisories and
    updated advisories, not just embargoed ones.

  * The list of entities on the pre-disclosure list will be made
    public.  We should probably warn the existing members of the
    predisclosure list that the fact that their organisation is on the
    list will be published and give them a chance to object or
    withdraw, so we will publish the actual list when the policy comes
    into force rather than right away.  I don''t expect any of the
    members to object.  We''re publishing organisation or vendor names,
    not email addresses, of course - the purpose is transparency, not
    spam.

  * Make it clear that we will share vulnerability information with
    other projects or vendors if we think the same problem may apply
    to them, or when it''s necessary to understand the problem and
    prepare the advisory.



            xen.org security problem response process
            -----------------------------------------

Introduction
------------

Computer systems have bugs.  Currently recognised best practice for
bugs with security implications is to notify significant downstream
users in private; leave a reasonable interval for downstreams to
respond and prepare updated software packages; then make public
disclosure.

We want to encourage people to report bugs they find to us.  Therefore
we will treat with respect the requests of discoverers, or other
vendors, who report problems to us.


Specific process
----------------

1. We request that anyone who discovers a vulnerability in xen.org
   software reports this by email to security (at) xen (dot) org.

   (This also covers the situation where an existing published
   changeset is retrospectively found to be a security fix.)

2. Immediately, and in parallel:

   (a) Those of us on the xen.org team who are aware of the problem
       will notify security@xen if disclosure wasn''t made there
       already.

   (b) If the vulnerability is not already public, security@xen will
       negotiate with discoverer regarding embargo date and disclosure
       schedule.  See below for detailed discussion.

3. Furthermore, also in parallel:

   (c) security@xen will check whether the discoverer, or other people
       already aware of the problem, have allocated a CVE number.  If
       not, we will acquire a CVE candidate number ourselves, and
       make sure that everyone who is aware of the problem is also
       aware of the CVE number.

   (d) If we think other software systems (for example, competing
       hypervisor systems) are likely to be affected by the same
       vulnerability, we will try to make those other projects aware
       of the problem and include them in the advisory preparation
       process.  (This may rely on the other project(s) having
       documented and responsive security contact points.)

   (e) We will prepare or check patch(es) which fix the vulnerability.
       This would ideally include all relevant backports.

   (f) We will determine which systems/configurations/versions are
       vulnerable, and what the impact of the vulnerability is.
       Depending on the nature of the vulnerability this may involve
       sharing information about the vulnerability (in confidence, if
       the issue is embargoed) with hardware vendors and/or other
       software projects.

   (g) We will write a Xen advisory including information from (b)-(f)

2. 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.

3. Advisory public release:

   At the embargo date we will publish the advisory, and push
   bugfix changesets to public revision control trees.

   Public advisories will be posted to xen-devel.

   Copies will also be sent to the pre-disclosure list, unless
   the advisory was already sent there previously during the embargo
   period and has not been updated since.

4. 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.


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@xen
     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. One working week 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.


Pre-disclosure list
-------------------

Xen.org operates a pre-disclosure list.  This list contains the email
addresses (ideally, role addresses) of the security response teams for
significant Xen operators and distributors.

This includes:
  - Large-scale hosting providers;
  - Large-scale organisational users of Xen;
  - Vendors of widely-deployed Xen-based systems;
  - Distributors of widely-deployed operating systems with Xen support.
This includes both corporations and community institutions.

Here as a rule of thumb "large scale" and "widely deployed"
means an
installed base of 300,000 or more Xen guests; other well-established
organisations with a mature security response process will be
considered on a case-by-case basis.

The list of entities on the pre-disclosure list is public.  (Just the
list of projects and organisations, not the actual email addresses.)

Pre-disclosure list members are expected to maintain the
confidentiality of the vulnerability up to the embargo date which
security@xen have agreed with the discoverer.

Specifically, prior to the embargo date, pre-disclosure list members
should not make available, even to their own customers and partners:
 - the Xen.org advisory
 - their own advisory
 - revision control commits which are a fix for the problem
 - patched software (even in binary form)
without prior consultation with security@xen and/or the discoverer.

Organisations who meet the criteria should contact security@xen if
they wish to receive pre-disclosure of advisories.

The pre-disclosure list will also receive copies of public advisories
when they are first issued or updated.

--

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I wrote:
> We received some comments and based on that I have prepared a new
> final draft.  The changes ought not to be controversial.
> 
> Please send any final comments by the 28th of July (14 days from
> now).  Unless there are objections, we will regard the process as
> formally in force from that date.
...
>    Public advisories will be posted to xen-devel.
We should send these also to some more general list.  So we should
probably post them oss-security [0].

And we should document in the process that we will CC the MITRE CVE
contact address with public advisories to try to make sure that the
MITRE database is updated.

Ian.

[0] http://oss-security.openwall.org/wiki/mailing-lists/oss-security

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Jackson <Ian.Jackson <at> eu.citrix.com> writes:
[...]
> 1. We request that anyone who discovers a vulnerability in xen.org
>    software reports this by email to security (at) xen (dot) org.
> 
>    (This also covers the situation where an existing published
>    changeset is retrospectively found to be a security fix.)
For this situation, the patch is already made public. Such information should be
shared with both the pre-disclosure and oss-security lists immediately, so that 
we can avoid having duplicated CVE names assigned.
>    (d) If we think other software systems (for example, competing
>        hypervisor systems) are likely to be affected by the same
>        vulnerability, we will try to make those other projects aware
>        of the problem and include them in the advisory preparation
>        process.  (This may rely on the other project(s) having
>        documented and responsive security contact points.)
There''s linux-distros@vs.openwall.org if you are unable to find the
necessary
security contacts.
> 3. Advisory public release:
> 
>    At the embargo date we will publish the advisory, and push
>    bugfix changesets to public revision control trees.
Perhaps be a bit more specific. At which timezone will the advisory be 
published? For the folks in Asia Pacific, this could mean a public pre-
disclosure of about 12 hours or more if security (at) xen is based in the 
States.
>    Public advisories will be posted to xen-devel.
> 
>    Copies will also be sent to the pre-disclosure list, unless
>    the advisory was already sent there previously during the embargo
>    period and has not been updated since.
And the oss-security list.
> Specifically, prior to the embargo date, pre-disclosure list members
> should not make available, even to their own customers and partners:
>  - the Xen.org advisory
>  - their own advisory
>  - revision control commits which are a fix for the problem
>  - patched software (even in binary form)
> without prior consultation with security <at> xen and/or the
discoverer.
Shouldn''t this be "and", instead of "and/or"? And
shouldn''t this includes prior
consultation with the list members too?

Thanks, Eugene
--
Eugene Teo / Red Hat Security Response Team


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

FYI Ian J is travelling and will be back online (at least partially,
depending on connectivity at debconf) probably on Monday.

On Wed, 2011-07-20 at 06:39 +0100, Eugene Teo wrote:
> Ian Jackson <Ian.Jackson <at> eu.citrix.com> writes:
> > 3. Advisory public release:
> > 
> >    At the embargo date we will publish the advisory, and push
> >    bugfix changesets to public revision control trees.
> 
> Perhaps be a bit more specific. At which timezone will the advisory be 
> published? For the folks in Asia Pacific, this could mean a public pre-
> disclosure of about 12 hours or more if security (at) xen is based in the 
> States.
The embargo date/time will be precise and include timezone information.

security@ is mostly based in the UK but since the embargo date is
subject to negotiation with the discoverer it is possible that the
advisory will be published during daylight hours in some other timezone.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Eugene Teo writes ("[Xen-devel] Re: Security vulnerability process - last
call"):
> Ian Jackson <Ian.Jackson <at> eu.citrix.com> writes:
> [...]
> > 1. We request that anyone who discovers a vulnerability in xen.org
> >    software reports this by email to security (at) xen (dot) org.
> > 
> >    (This also covers the situation where an existing published
> >    changeset is retrospectively found to be a security fix.)
> 
> For this situation, the patch is already made public. Such
> information should be shared with both the pre-disclosure and
> oss-security lists immediately, so that we can avoid having
> duplicated CVE names assigned.
"Immediately" might be OK for oss-security.  But the I don''t
think we
want to send half-digested information to the predisclosure list.

I will add something to the draft to say we will tell oss-security
right away in this situation.
> >    (d) If we think other software systems (for example, competing
> >        hypervisor systems) are likely to be affected by the same
> >        vulnerability, we will try to make those other projects aware
> >        of the problem and include them in the advisory preparation
> >        process.  (This may rely on the other project(s) having
> >        documented and responsive security contact points.)
> 
> There''s linux-distros@vs.openwall.org if you are unable to find
the
> necessary security contacts.
Noted, thanks.
> > 3. Advisory public release:
> > 
> >    At the embargo date we will publish the advisory, and push
> >    bugfix changesets to public revision control trees.
> 
> Perhaps be a bit more specific. At which timezone will the advisory be 
> published? For the folks in Asia Pacific, this could mean a public pre-
> disclosure of about 12 hours or more if security (at) xen is based in the 
> States.
As Ian C said, the advisory will state the a specific time, with
timezone, for the end of the embargo.  That will probably normally be
between 1200 UTC and 1600 UTC simply because of the timezone where
most of the xen.org security team are based.

Do you need something specific written in the process document about
this ?
> >    Public advisories will be posted to xen-devel.
> > 
> >    Copies will also be sent to the pre-disclosure list, unless
> >    the advisory was already sent there previously during the embargo
> >    period and has not been updated since.
> 
> And the oss-security list.
Right.
> > Specifically, prior to the embargo date, pre-disclosure list members
> > should not make available, even to their own customers and partners:
> >  - the Xen.org advisory
> >  - their own advisory
> >  - revision control commits which are a fix for the problem
> >  - patched software (even in binary form)
> > without prior consultation with security <at> xen and/or the
discoverer.
> 
> Shouldn''t this be "and", instead of "and/or"?
And shouldn''t this
> includes prior consultation with the list members too?
I think if the discoverer tells a downstream to publish something, and
doesn''t consult us, that''s up to the discoverer.  It
shouldn''t include
prior consultation with the pre-disclosure list members because that''s
not a discussion list.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel