[<prev] [next>] [day] [month] [year] [list]
Message-Id: <E1Zrlsd-00025q-DJ@xenbits.xen.org>
Date: Thu, 29 Oct 2015 12:00:31 +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 149 (CVE-2015-7969) - leak of main
per-domain vcpu pointer array
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2015-7969 / XSA-149
version 3
leak of main per-domain vcpu pointer array
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
A domain's primary array of vcpu pointers can be allocated by a
toolstack exactly once in the lifetime of a domain via the
XEN_DOMCTL_max_vcpus hypercall.
This array is leaked on domain teardown. This memory leak could --
over time -- exhaust the host's memory.
IMPACT
======
A domain given partial management control via XEN_DOMCTL_max_vcpus can
mount a denial of service attack affecting the whole system.
The ability to also restart or create suitable domains is also
required to fully exploit the issue. Without this the leak is limited
to a small multiple of the maximum number of vcpus for the domain.
The maximum leak is 64kbytes per domain (re)boot (less on ARM).
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, or OpenStack
(unless substantially modified or supplemented, as compared to
versions supplied by the respective upstreams).
Versions of Xen from 4.0 onwards are vulnerable.
All architectures are affected.
MITIGATION
==========
The leak is small. Preventing the creation of large numbers of new
domains, and limiting the number of times an existing domain can be
rebooted, can reduce the impact of this vulnerability.
Switching from disaggregated to a non-disaggregated operation does NOT
mitigate the XEN_DOMCTL_max_vcpus vulnerability. 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.
NOTE REGARDING CVE
==================
Note that CVE-2015-7969 covers both this issue and XSA-151.
CREDITS
=======
This issue was discovered by Ian Campbell of Citrix.
RESOLUTION
==========
Applying the attached patch resolves this issue.
(To resolve CVE-2015-7969, the patch from XSA-151 is required too.)
xsa149.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x
$ sha256sum xsa149*.patch
e01628400b81c4bb7bafba348f2ecb1fe80f16e3162cee5013e0be1d7311738b xsa149.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the PATCH (or others which are substantially similar) is
permitted during the embargo, even on public-facing systems with
untrusted guest users and administrators.
However deployment of the (RE)BOOT LIMIT MITIGATION is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List). Specifically, deployment on
public cloud systems is NOT permitted.
This is because applying domain creation and reboot limits in
connection with a security issue would be a user-visible change which
could lead to the rediscovery of the vulnerability.
Deployment of the mitigation is permitted only AFTER the embargo ends.
Also: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJWMgm7AAoJEIP+FMlX6CvZ5EEH/RpWXVKVpA5JdTGGfWan9ojV
+9Froz+RdUJmINLHE/sIIAudfCIlc7zA1Ap/ukSUC9YfBZvjwMpiouTz2IJV+kgp
C0zTjTHrqf0RG7k9aXKTqDNhHWP/FukVv6V4KZ+vmC9CluV8ODhnvogO0bS4wO2y
dzJAtQZxhD1r0rgvLWlT0Wq0LylTqW6mXg0lHiBv+HFonKJAIEeg/0dJbriKsc0N
1+vI4DujVzE1Q3LuhkGtaxdGyZ/4rcfMexmIYHzpvehHLXKa63oHg7IGX2SchiKb
YFumc9K3sYdv+AHkqM9FdtKEgDvwcHL9+d4YVgGfQm9ukh2onEC6uw7VeVnPlXY=
=/Ww0
-----END PGP SIGNATURE-----
Download attachment "xsa149.patch" of type "application/octet-stream" (510 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.
