Xen.org Security Problem Response Process
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.
Scope of this process
This process primarily covers the Xen Hypervisor Project. Vulnerabilties reported against other Xen.org projects will be handled on a best effort basis by the relevant Project Lead together with the security team.
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)
Immediately, and in parallel:
Those of us on the xen.org team who are aware of the problem
will notify security@xen if disclosure wasn't made there
If the vulnerability is not already public, security@xen will
negotiate with discoverer regarding embargo date and disclosure
schedule. See below for detailed discussion.
- Furthermore, also in parallel:
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.
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
(This may rely on the other project(s) having
documented and responsive security contact points)
We will prepare or check patch(es) which fix the
vulnerability. This would ideally include all relevant
backports. Patches will be tightly targeted on fixing the
specific security vulnerability in the smallest, simplest and
most reliable way. Where necessary domain specific experts
within the community will be brought in to help with patch
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
We will write a Xen advisory including information from (b)-(f)
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
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,
xen-users and xen-annnounce and will be added to the
Security Announcements wiki page.
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.
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
Post embargo transparency:
During an embargo period the Xen.org security response team may
be required to make potentially controverial decisions in private,
since they cannot confer with the community without breaking the
embargo. The security team will attempt to make such decisions
following the guidance of this document and where necessary their
own best judgement. Following the embargo period any such
decisions will be disclosed to the community in the interests of
transparency and to help provide guidance should a similar
decision be required in the future.
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:
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.
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.
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.
- 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
- the impact, scope, set of vulnerable systems or the nature
of the vulnerability
- 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.
List members are allowed to make available to their users only the following:
- The existance of an issue
- The assigned XSA and CVE numbers
- The planned disclosure date
Organisations who meet the criteria should contact security@xen if they wish to receive pre-disclosure of advisories. Organisations should not request subscription via the mailing list web interface, any such subscription requests will be rejected and ignored.
Normally we would prefer that a role address be used for each organisation, rather than one or more individual's direct email address. This helps to ensure that changes of personnel do not end up effectively dropping an organisation from the list
The pre-disclosure list will also receive copies of public advisories when they are first issued or updated.
Organizations on the pre-disclosure list:
This is a list of organisations on the pre-disclosure list
(not email addresses or internal business groups).
- Invisible Things Lab
- Xen.org security response team
- Xen 3.4 stable tree maintainer
- v1.5 Nov 2012: Added Invisible Things Lab to pre-disclosure list
- v1.4 Oct 2012: Various minor updates
- v1.3 Sept 2012: Added CentOS to pre-disclosure list
- v1.2 Apr 2012: Added pre-disclosure list
- v1.1 Feb 2012: Added link to Security Announcements wiki page
- v1.0 Dec 2011: Intial document published after review