[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-announce] Xen Security Advisory 15 (CVE-2012-3497) - multiple TMEM hypercall vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2012-3497 / XSA-15
multiple TMEM hypercall vulnerabilities
UPDATES IN VERSION 2
Public release. Credit Matthew Daley.
Several sub-operations of the Transcendent Memory (TMEM) hypercall
either do not correctly validate their inputs, do not correctly
validate the privilege of the calling guest, or have other
A full list of the vulnerabilities in the TMEM system is not available
An unprivileged guest can overwrite hypervisor owned memory with the
content of their choosing allowing them to escalate their privilege to
that of the host.
In addition an unprivileged guest can also crash the hypervisor,
leading to a Denial of Service attack.
ONLY installations where "tmem" is specified on the hypervisor command
line are vulnerable. Most Xen installations do not do so.
All versions of Xen from 4.0 onward which have TMEM enabled and are
running guests with untrusted administrators are vulnerable.
Although we consider it unlikely, we have not been able to rule out
the possibility that an malicious unprivileged user could exploit
these issues via a trusted TMEM-aware kernel. Therefore all
administrators are advised to disable TMEM even if all guest kernels
are controlled and trusted.
Only systems which have TMEM enabled at boot time are affected by this
issue. By default TMEM is disabled unless it is explicitly enabled
via the hypervisor command line option "tmem".
TMEM has been described by its maintainers as a technology preview,
and is therefore not supported by them for use in production systems.
Pending a full security audit of the code, the Xen.org security team
recommends that Xen users do not enable TMEM.
Work is ongoing, by the community maintainers for TMEM, to patch the
specific bugs as they are found. This includes both the multiple
vulnerabilities initially reported to the Xen.org security team, and
multiple further vulnerabilities which have been discovered since then
during our ad-hoc code inspection.
At the time of writing, a complete set of fixes even for known issues
is not available.
PROCESS FOR TMEM VULNERABILITIES
Until TMEM has gained production maturity, the Xen.org security team
intends (subject of course to the permission of anyone disclosing to
us) to handle these and future TMEM vulnerabilities in public, as if
they were normal non-security-related bugs.
We therefore intend that currently-known vulnerabilities will be
publicly disclosed on the xen-devel mailing list, as normal bug
reports, at the expiry of the XSA-15 embargo. In the meantime the
list below may be helpful.
Xen.org security team will ensure, on expiry of the embargo, that the
documentation reflects TMEM's technology preview status.
Thanks to Matthew Daley for finding these vulnerabilities (and that in
XSA-12) and notifying the Xen.org security team.
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 TMEM vulnerabilities', above.
Multiple tmem save-related control ops do not check for NULL
TMEMC_SAVE_GET_CLIENT_FLAGS and TMEMC_SAVE_END do not check
that the cli_id used to find the client is valid, and can
hence dereference a NULL client. This allows a malicious
guest to crash the host (DoS), or, in the case of
TMEMC_SAVE_END, memory corruption (DoS or worse).
Multiple tmem save-related control ops do not check guest output
The functions tmemc_save_get_next_page,
tmemc_save_get_next_inv and the TMEMC_SAVE_GET_POOL_UUID
subop do not check incoming guest output buffer pointers,
and do not use ie. copy_to_guest. A malicious guest can
crash the host or cause memory corruption (DoS / code
Multiple tmem ops do not check for negative pool IDs:
The functions tmemc_save_get_next_page,
tmemc_restore_put_page and tmemc_restore_flush_page do not
check for negative pool IDs, allowing (at least) memory
do_tmem_destroy_pool does not check for invalid pool IDs:
The function do_tmem_destroy_pool does not check for invalid
pool IDs, allowing a malicious guest to crash the host or
corrupt host memory (DoS / code execution).
do_tmem_control's privilege check is commented out:
This allows any guest access to control stack operations
(many of which themselves do not have adequate argument
tmh_copy_from_client and tmh_copy_to_client have an integer
This can corrupt host memory.
do_tmem_get()'s bad_copy error path leaves a spinlock held:
The next operation on the same object will hang the CPU.
This is a host DoS.
do_tmem_op has at least one error path with broken locking checks:
This is a host DoS or worse.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
Xen-announce mailing list