[prev in list] [next in list] [prev in thread] [next in thread]
List: xen-announce
Subject: [Xen-announce] Xen Security Advisory 92 (CVE-2014-3124) - HVMOP_set_mem_type allows invalid P2M entr
From: Xen.org security team <security () xen ! org>
Date: 2014-05-01 10:54:27
Message-ID: E1WfodH-0004Jw-FC () xenbits ! xen ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2014-3124 / XSA-92
version 3
HVMOP_set_mem_type allows invalid P2M entries to be created
UPDATES IN VERSION 3
====================
This issue has been assigned CVE-2014-3124.
ISSUE DESCRIPTION
=================
The implementation in Xen of the HVMOP_set_mem_type HVM control
operations attempts to exclude transitioning a page from an
inappropriate memory type. However, only an inadequate subset of
memory types is excluded.
There are certain other types that don't correspond to a particular
valid page, whose page table translation can be inappropriately
changed (by HVMOP_set_mem_type) from not-present (due to the lack of
valid memory page) to present. If this occurs, an invalid translation
will be established.
IMPACT
======
In a configuration where device models run with limited privilege (for
example, stubdom device models), a guest attacker who successfully
finds and exploits an unfixed security flaw in qemu-dm could leverage
the other flaw into a Denial of Service affecting the whole host.
In the more general case, in more abstract terms: a malicious
administrator of a domain privileged with regard to an HVM guest can
cause Xen to crash leading to a Denial of Service.
Arbitrary code execution, and therefore privilege escalation, cannot
be entirely excluded: On a system with a RAM page present immediately
below the 52-bit address boundary, this would be possible. However,
we are not aware of any systems with such a memory layout.
VULNERABLE SYSTEMS
==================
All Xen versions from 4.1 onwards are vulnerable.
The vulnerability is only exposed to service domains for HVM guests
which have privilege over the guest. In a usual configuration that
means only device model emulators (qemu-dm).
In the case of HVM guests whose device model is running in an
unrestricted dom0 process, qemu-dm already has the ability to cause
problems for the whole system. So in that case the vulnerability is
not applicable.
The situation is more subtle for an HVM guest with a stub qemu-dm.
That is, where the device model runs in a separate domain (in the case
of xl, as requested by "device_model_stubdomain_override=1" in the xl
domain configuration file). The same applies with a qemu-dm in a dom0
process subjected to some kind kernel-based process privilege
limitation (eg the chroot technique as found in some versions of
XCP/XenServer).
In those latter situations this issue means that the extra isolation
does not provide as good a defence (against denial of service) as
intended. That is the essence of this vulnerability.
However, the security is still better than with a qemu-dm running as
an unrestricted dom0 process. Therefore users with these
configurations should not switch to an unrestricted dom0 qemu-dm.
Finally, in a radically disaggregated system: where the HVM service
domain software (probably, the device model domain image) is not
always supplied by the host administrator, a malicious service domain
administrator can exercise this vulnerability.
MITIGATION
==========
Running only PV guests will avoid this vulnerability.
In a radically disaggregated system, restricting HVM service domains
to software images approved by the host administrator will avoid the
vulnerability.
CREDITS
=======
This issue was discovered by Jan Beulich.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa92.patch xen-unstable, Xen 4.4.x, Xen 4.3.x
xsa92-4.2.patch Xen 4.2.x
xsa92-4.1.patch Xen 4.1.x
$ sha256sum xsa92*.patch
184dcb88dfb4540fca33016ffcfe0f4f557449ab5b4ec6a4bf486c75926d23f3 xsa92.patch
76905398958dfcec98fb5bde2a68c0e86a3ccc9f442a8a658e972937fd75534a xsa92-4.1.patch
bca98827834f807c787fceb6c719d9d4fe3c40786cb087156829e5e6fb5700d6 xsa92-4.2.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJTYidfAAoJEIP+FMlX6CvZ6m0H/0khx5ZZ0MiEf52szuhdBoCe
zmNRuD8FrjS16CQx6KIUvvlLujWHg3hE+PFAoV3tM5U9++WrvXVO8o1ckKysle26
udRignUc1Y+Am5nB1p1KRwpVb4v8votb+/GJfFlYd01V4wyaMttQLJkI9jcLRMN7
f0bcttCZTTToQGpl6DuYh1NCOc1mLEtlC66SAHvvA8jC6K395M/MsSs+lkB63AHW
SS2kdatHpt3BH4zSPRZQiwStMTCYMPN3+oc9BX1N1DphbqKo5yC1WaamF//24Ew9
ZDjtBgjQhJfZ9IKPbRctsxKOrObEfkcLLO3ETaZ74MHl94I000L+lfki7D8Gk+k=
=xTcW
-----END PGP SIGNATURE-----
["xsa92.patch" (application/octet-stream)]
x86/HVM: restrict HVMOP_set_mem_type
Permitting arbitrary type changes here has the potential of creating
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
MFN (INVALID_MFN truncated to the respective hardware structure field's
width). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.
Along with that drop a bogus (and otherwise becoming stale) log
message.
Afaict the similar operation in p2m_set_mem_access() is safe.
This is XSA-92.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4541,12 +4541,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
rc = -EINVAL;
goto param_fail4;
}
- if ( p2m_is_grant(t) )
+ if ( !p2m_is_ram(t) &&
+ (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
{
put_gfn(d, pfn);
- gdprintk(XENLOG_WARNING,
- "type for pfn %#lx changed to grant while "
- "we were working?\n", pfn);
goto param_fail4;
}
else
["xsa92-4.1.patch" (application/octet-stream)]
x86/HVM: restrict HVMOP_set_mem_type
Permitting arbitrary type changes here has the potential of creating
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
MFN (INVALID_MFN truncated to the respective hardware structure field's
width). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.
Along with that drop a bogus (and otherwise becoming stale) log
message.
Afaict the similar operation in p2m_set_mem_access() is safe.
This is XSA-92.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3666,13 +3666,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
rc = -EINVAL;
goto param_fail4;
}
- if ( p2m_is_grant(t) )
- {
- gdprintk(XENLOG_WARNING,
- "type for pfn 0x%lx changed to grant while "
- "we were working?\n", pfn);
+ if ( !p2m_is_ram(t) &&
+ (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
goto param_fail4;
- }
else
{
nt = p2m_change_type(p2m, pfn, t, memtype[a.hvmmem_type]);
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -134,6 +134,13 @@ typedef enum {
| p2m_to_mask(p2m_ram_paging_in) \
| p2m_to_mask(p2m_ram_shared))
+/* Types that represent a physmap hole. */
+#define P2M_HOLE_TYPES (p2m_to_mask(p2m_mmio_dm) \
+ | p2m_to_mask(p2m_invalid) \
+ | p2m_to_mask(p2m_ram_paging_in_start) \
+ | p2m_to_mask(p2m_ram_paging_in) \
+ | p2m_to_mask(p2m_ram_paged))
+
/* Grant mapping types, which map to a real machine frame in another
* VM */
#define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) \
@@ -170,6 +177,7 @@ typedef enum {
/* Useful predicates */
#define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES)
+#define p2m_is_hole(_t) (p2m_to_mask(_t) & P2M_HOLE_TYPES)
#define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES)
#define p2m_is_readonly(_t) (p2m_to_mask(_t) & P2M_RO_TYPES)
#define p2m_is_magic(_t) (p2m_to_mask(_t) & P2M_MAGIC_TYPES)
["xsa92-4.2.patch" (application/octet-stream)]
x86/HVM: restrict HVMOP_set_mem_type
Permitting arbitrary type changes here has the potential of creating
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
MFN (INVALID_MFN truncated to the respective hardware structure field's
width). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.
Along with that drop a bogus (and otherwise becoming stale) log
message.
Afaict the similar operation in p2m_set_mem_access() is safe.
This is XSA-92.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4245,12 +4245,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
rc = -EINVAL;
goto param_fail4;
}
- if ( p2m_is_grant(t) )
+ if ( !p2m_is_ram(t) &&
+ (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
{
put_gfn(d, pfn);
- gdprintk(XENLOG_WARNING,
- "type for pfn 0x%lx changed to grant while "
- "we were working?\n", pfn);
goto param_fail4;
}
else
_______________________________________________
Xen-announce mailing list
Xen-announce@lists.xen.org
http://lists.xen.org/xen-announce
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic