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.