[<prev] [next>] [day] [month] [year] [list]
Message-Id: <E1VqMtR-0007D8-OW@xenbits.xen.org>
Date: Tue, 10 Dec 2013 12:58:29 +0000
From: Xen.org security team <security@....org>
To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org,
xen-users@...ts.xen.org, oss-security@...ts.openwall.com
CC: Xen.org security team <security@....org>
Subject: Xen Security Advisory 77 - Disaggregated domain management
security status
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory XSA-77
version 3
Disaggregated domain management security status
UPDATES IN VERSION 3
====================
Public release.
The included documentation patch now updates the xsm-flash.txt
documentation rather than the Xen public headers. The advisory has
been updated to reflect this.
Made the warning about the documentation patch stand out more clearly.
ISSUE DESCRIPTION
=================
Xen supports disaggregation of various support and management
functions into their own domains; this is often done for security and
robustness reasons.
In Xen 4.3 additional functionality was introduced to allow further
disaggregation: the Xen Security Modules mechanism was enhanced to
make it possible to delegate various domain control hypercalls to
particular other domains, rather than only permitting use by dom0.
However the several affected hypercall implementations were
originally written to be used only by the totally-privileged dom0, and
have not been reviewed for security when exposed to
supposedly-only-semi-privileged disaggregated management domains. But
such management domains are (in such a design) to be seen as
potentially hostile, e.g. due to privilege escalation following
exploitation of a bug in the management domain.
As a result, the potential security benefits of toolstack
disaggregation are not always fully realised. This constitutes a
breach of the enhanced security promises implied by the Xen APIs in
Xen in 4.3 and later.
The affected hypercalls are:
__HYPERVISOR_domctl: The majority of the XEN_DOMCTL_* subops are
affected. Exceptions are listed below.
__HYPERVISOR_sysctl: All XEN_SYSCTL_* subops are affected.
__HYPERVISOR_memory_op: A small number of XENMEM_* subops are
affected. See below.
__HYPERVISOR_tmem_op: All TMEMC_* sub-subops of the TMEM_CONTROL
subop are affected.
The majority of the domctls are subject to this issue. Prior to 4.3,
only the following domctls were disaggregatable, and they are NOT
affected by these problems:
XEN_DOMCTL_ioport_mapping XEN_DOMCTL_bind_pt_irq
XEN_DOMCTL_memory_mapping XEN_DOMCTL_unbind_pt_irq
The implementations of these were written with semi-trusted callers
in mind.
Only the following memory op subops are affected:
XENMEM_set_pod_target XENMEM_get_pod_target
XENMEM_claim_pages
The remainder of the memory ops were written with untrusted or
semi-trusted callers in mind.
IMPACT
======
Domains deliberately given partial management control may be able to
deny service to the entire host or even escalate their privileges.
As a result, in a system designed to enhance security by radically
disaggregating the management, the security may be reduced. But, the
security will be no worse than a non-disaggregated design.
VULNERABLE SYSTEMS
==================
This issue is only relevant to systems which intend to increase
security through the use of advanced disaggregated management
techniques.
This does not include systems using libxl, libvirt, xm/xend,
XCP/XenServer, OpenStack or CloudStack (unless substantially modified
or supplemented, as compared to versions supplied by the respective
upstreams).
This issue is not relevant to stub device models, driver domains, or
stub xenstored. Those disaggregation techniques do not rely on
granting the semi-privileged support domains access to the affected
interfaces, and are believed to provide the intended security
benefits.
This issue is only relevant to Xen 4.3 and xen-unstable, and not to
any earlier version.
PROCESS FOR VULNERABILITIES IN AFFECTED INTERFACES
==================================================
Until the interfaces have been properly reviewed for security against
hostile callers, the Xen.org security team intends (subject of course
to the permission of anyone disclosing to us) to handle these and
future vulnerabilities in these interfaces in public, as if they were
normal non-security-related bugs.
This applies only to bugs which do no more than reduce the security of
a radically disaggregated system to the security of a
non-disaggregated one. Here a "radically disaggregated system" is one
which uses the XSM mechanism to delegate the affected interfaces to
other-than-fully-trusted domains.
This policy does not apply to bugs which affect stub device models,
driver domains, or stub xenstored - even if those bugs do no worse
than reduce the security of such a system to one whose device models,
backend drivers, or xenstore, run in dom0.
The list of interfaces which are subject to the above process
exception are listed in the Xen Source tree in docs/misc/xsm-flask
under the heading "Security Status of dom0 disaggregation". This
document is also available at
http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt.
We intend that currently-known problems will be publicly disclosed on
the xen-devel mailing list, as normal bug reports, at the expiry of
the XSA-77 embargo.
In the meantime the list below may be helpful.
MITIGATION
==========
The issues discussed in this advisory are themselves bugs in features
used for a security risk mitigation.
There is no further mitigation available, beyond general measures to
try to avoid parts of the system management becoming controlled by
attackers. Those are the kind of measures which we expect any users
of radical disaggregation to have already deployed.
Switching from disaggregated to a non-disaggregated operation does NOT
mitigate these vulnerabilities. Rather, it simply recategorises the
vulnerability to hostile management code, regarding it "as designed";
thus it merely reclassifies these issues as "not a bug".
Users and vendors of disaggregated systems should not change their
configuration. The robustness benefits of disaggregation are
unaffected, and (depending on system design) security benefits are
likely to remain despite the vulnerabilities.
RESOLUTION
==========
We hope that the control interface attack surface can be reviewed and
improved so that disaggregation can deliver its security benefits more
fully.
Patches resulting from this process will be developed in public and
applied to the Xen trees as if they were ordinary bugfixes.
In the meantime the attached patch will be applied to the unstable
branch in order to track which interfaces are subject to this
exception.
This patch is purely documentary and DOES NOT resolve any issue.
$ sha256sum xsa77*.patch
bd9daffa8abfb05fb4a474e903dcd777352a705c1cf6e89343ea6545d545e4cb xsa77-unstable.patch
$
CREDITS
=======
The issues which prompted this advisory were discovered by Jan
Beulich and Don Slutz.
LIST OF KNOWN VULNERABILITIES
=============================
**NOTE** that this is unlikely to be a complete list of problems.
**NOTE** that after publication of this advisory, after the embargo
ends, the advisory will no longer be updated to extend this list of
vulnerabilities. See `Process for domctl vulnerabilities', above.
Multiple domctls can be made, by the caller, to perform excessively
long-running operations. This can result in host-wide denial of
service and watchdog-induced crashes.
XEN_DOMCTL_gethvmcontext_partial allows access to guest state, in
particular certain pieces that are per-vCPU. If one or more of a
guest's vCPU-s are offline, the space internally allocated to store
each individual vCPU's state would not get fully used and, due to
another bug, information from the portion that didn't get initialized
may be returned back to the caller.
In the course of processing the request to set register state for
another PV guest's vCPU, the hypervisor updated the in memory copy of
the debug register values twice - first by simply copying over the
values, and in a second step through code properly verifying them.
Between the two operations there are, however, other error exit paths,
making it possible that unvalidated state could remain in place and be
loaded when the vCPU is next scheduled to run.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJSpw/NAAoJEIP+FMlX6CvZBskH/j4YsHS48A82IEez4Zn7m+m6
n2d3UjT7fAAgxvqD3YJ7gsZI0Xi4PKw4ThHmmV6ZIdE18jju9ByrcsLLA/z77sO4
eUEastK49XKQ1Him7v+XB2/zfZ2ty/grnWS9dk5r18hVQLv+KIuQoyB+/QHt3bD4
i06R6iyhE57yJiD72bTNflITioyuZybMG/MM+7Pby8OVblagNgUS3YK9Z5J246/e
fWDTUsgI6c63zWRjqwBZB0vI+omr/GfNUX0e77LMnv/f/X6jwVBdNML2RDI9HDRO
lWdfQQeYHQN/mK6OD5s13+qIonv3iq8wJjeRxvQpQKAnjynFu61VDnp/ghN6xnE=
=lQLn
-----END PGP SIGNATURE-----
Download attachment "xsa77-unstable.patch" of type "application/octet-stream" (7024 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
