[prev in list] [next in list] [prev in thread] [next in thread]
List: xen-users
Subject: [Xen-users] Xen Security Advisory 191 (CVE-2016-9386) - x86 null segments not always treated as unus
From: Xen.org security team <security () xen ! org>
Date: 2016-11-22 12:02:05
Message-ID: E1c99m1-00083i-DF () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2016-9386 / XSA-191
version 3
x86 null segments not always treated as unusable
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
The Xen x86 emulator erroneously failed to consider the unusability of
segments when performing memory accesses.
The intended behaviour is as follows: The user data segment (%ds, %es,
%fs and %gs) selectors may be NULL in 32-bit to prevent access. In
64-bit, NULL has a special meaning for user segments, and there is no
way of preventing access. However, in both 32-bit and 64-bit, a NULL
LDT system segment is intended to prevent access.
On Intel hardware, loading a NULL selector zeros the base as well as most
attributes, but sets the limit field to its largest possible value. On AMD
hardware, loading a NULL selector zeros the attributes, leaving the stale base
and limit intact.
Xen may erroneously permit the access using unexpected base/limit values.
Ability to exploit this vulnerability on Intel is easy, but on AMD depends in
a complicated way on how the guest kernel manages LDTs.
IMPACT
======
An unprivileged guest user program may be able to elevate its privilege
to that of the guest operating system.
VULNERABLE SYSTEMS
==================
The vulnerability is only exposed to HVM guests.
ARM systems are NOT vulnerable.
All versions of Xen are affected.
However, we believe that the vulnerability cannot be exploited on Xen
4.7 by completely unprivileged guest processes, unless the VM has been
explicitly configured with a non-default cpu vendor string (in xm/xl,
this would be done with a `cpuid=' domain config option).
MITIGATION
==========
Running only PV guests will avoid this issue.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa191.patch xen-unstable, Xen 4.7.x
xsa191-4.6.patch Xen 4.6.x, Xen 4.5.x, Xen 4.4.x
$ sha256sum xsa191*
dca534cf4d3711ea8797846a18238ca16cc9e7a24a887300db22c3ba3d95c199 xsa191.patch
d95a1f0dd5c45497ca56e2e1390fc688bf0a4a7a7fd10c65ae25b4bbb3353b69 xsa191-4.6.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: 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
iQEcBAEBAgAGBQJYNDIWAAoJEIP+FMlX6CvZ4qQH/jlfd6BV63CSggCQVd0sB3a4
j7MgRZ8h0aFrCLl+0tj3QwsiW0TRDsKiTNy2xY1kxkLsQdIAeYjBddyYiJ2nbCr9
kCR2WLcWB3csf4So/85q8OMfsob7H+8PR/OsT3iY6Fo/5PzNy5wvWtU/+TRaoZIy
t9OvybZ0HYhtvQ/YHv5njKZ3nyHo6MRwGpPOrzSn8UN7p+sr3DDGiuw9LNjtnepb
dijO0c9artbWCjVkRlbe1w5514FH1vPleopGmXjTz/Wy5zNHWZL1RaVzh4N36ahP
V1joPxt+C75iRArp6y0ncloyKjgx8pMfOzCcLp9VS6dwF3zwZ5rxxtFynlRjg94=
=pUW4
-----END PGP SIGNATURE-----
["xsa191.patch" (application/octet-stream)]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/hvm: Fix the handling of non-present segments
In 32bit, the data segments may be NULL to indicate that the segment is
ineligible for use. In both 32bit and 64bit, the LDT selector may be NULL to
indicate that the entire LDT is ineligible for use. However, nothing in Xen
actually checks for this condition when performing other segmentation
checks. (Note however that limit and writeability checks are correctly
performed).
Neither Intel nor AMD specify the exact behaviour of loading a NULL segment.
Experimentally, AMD zeroes all attributes but leaves the base and limit
unmodified. Intel zeroes the base, sets the limit to 0xfffffff and resets the
attributes to just .G and .D/B.
The use of the segment information in the VMCB/VMCS is equivalent to a native
pipeline interacting with the segment cache. The present bit can therefore
have a subtly different meaning, and it is now cooked to uniformly indicate
whether the segment is usable or not.
GDTR and IDTR don't have access rights like the other segments, but for
consistency, they are treated as being present so no special casing is needed
elsewhere in the segmentation logic.
AMD hardware does not consider the present bit for %cs and %tr, and will
function as if they were present. They are therefore unconditionally set to
present when reading information from the VMCB, to maintain the new meaning of
usability.
Intel hardware has a separate unusable bit in the VMCS segment attributes.
This bit is inverted and stored in the present field, so the hvm code can work
with architecturally-common state.
This is XSA-191.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/hvm/hvm.c | 8 ++++++++
xen/arch/x86/hvm/svm/svm.c | 4 ++++
xen/arch/x86/hvm/vmx/vmx.c | 20 +++++++++++---------
xen/arch/x86/x86_emulate/x86_emulate.c | 4 ++++
4 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 704fd64..deb1783 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2512,6 +2512,10 @@ bool_t hvm_virtual_to_linear_addr(
*/
addr = (uint32_t)(addr + reg->base);
+ /* Segment not valid for use (cooked meaning of .p)? */
+ if ( !reg->attr.fields.p )
+ goto out;
+
switch ( access_type )
{
case hvm_access_read:
@@ -2767,6 +2771,10 @@ static int hvm_load_segment_selector(
hvm_get_segment_register(
v, (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr, &desctab);
+ /* Segment not valid for use (cooked meaning of .p)? */
+ if ( !desctab.attr.fields.p )
+ goto fail;
+
/* Check against descriptor table limit. */
if ( ((sel & 0xfff8) + 7) > desctab.limit )
goto fail;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 16427f6..4cba406 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -627,6 +627,7 @@ static void svm_get_segment_register(struct vcpu *v, enum x86_segment seg,
{
case x86_seg_cs:
memcpy(reg, &vmcb->cs, sizeof(*reg));
+ reg->attr.fields.p = 1;
reg->attr.fields.g = reg->limit > 0xFFFFF;
break;
case x86_seg_ds:
@@ -660,13 +661,16 @@ static void svm_get_segment_register(struct vcpu *v, enum x86_segment seg,
case x86_seg_tr:
svm_sync_vmcb(v);
memcpy(reg, &vmcb->tr, sizeof(*reg));
+ reg->attr.fields.p = 1;
reg->attr.fields.type |= 0x2;
break;
case x86_seg_gdtr:
memcpy(reg, &vmcb->gdtr, sizeof(*reg));
+ reg->attr.bytes = 0x80;
break;
case x86_seg_idtr:
memcpy(reg, &vmcb->idtr, sizeof(*reg));
+ reg->attr.bytes = 0x80;
break;
case x86_seg_ldtr:
svm_sync_vmcb(v);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9a8f694..a652c52 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1035,10 +1035,12 @@ void vmx_get_segment_register(struct vcpu *v, enum x86_segment seg,
reg->sel = sel;
reg->limit = limit;
- reg->attr.bytes = (attr & 0xff) | ((attr >> 4) & 0xf00);
- /* Unusable flag is folded into Present flag. */
- if ( attr & (1u<<16) )
- reg->attr.fields.p = 0;
+ /*
+ * Fold VT-x representation into Xen's representation. The Present bit is
+ * unconditionally set to the inverse of unusable.
+ */
+ reg->attr.bytes =
+ (!(attr & (1u << 16)) << 7) | (attr & 0x7f) | ((attr >> 4) & 0xf00);
/* Adjust for virtual 8086 mode */
if ( v->arch.hvm_vmx.vmx_realmode && seg <= x86_seg_tr
@@ -1118,11 +1120,11 @@ static void vmx_set_segment_register(struct vcpu *v, enum x86_segment seg,
}
}
- attr = ((attr & 0xf00) << 4) | (attr & 0xff);
-
- /* Not-present must mean unusable. */
- if ( !reg->attr.fields.p )
- attr |= (1u << 16);
+ /*
+ * Unfold Xen representation into VT-x representation. The unusable bit
+ * is unconditionally set to the inverse of present.
+ */
+ attr = (!(attr & (1u << 7)) << 16) | ((attr & 0xf00) << 4) | (attr & 0xff);
/* VMX has strict consistency requirement for flag G. */
attr |= !!(limit >> 20) << 15;
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index 7a707dc..7cb6f98 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1367,6 +1367,10 @@ protmode_load_seg(
&desctab, ctxt)) )
return rc;
+ /* Segment not valid for use (cooked meaning of .p)? */
+ if ( !desctab.attr.fields.p )
+ goto raise_exn;
+
/* Check against descriptor table limit. */
if ( ((sel & 0xfff8) + 7) > desctab.limit )
goto raise_exn;
["xsa191-4.6.patch" (application/octet-stream)]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/hvm: Fix the handling of non-present segments
In 32bit, the data segments may be NULL to indicate that the segment is
ineligible for use. In both 32bit and 64bit, the LDT selector may be NULL to
indicate that the entire LDT is ineligible for use. However, nothing in Xen
actually checks for this condition when performing other segmentation
checks. (Note however that limit and writeability checks are correctly
performed).
Neither Intel nor AMD specify the exact behaviour of loading a NULL segment.
Experimentally, AMD zeroes all attributes but leaves the base and limit
unmodified. Intel zeroes the base, sets the limit to 0xfffffff and resets the
attributes to just .G and .D/B.
The use of the segment information in the VMCB/VMCS is equivalent to a native
pipeline interacting with the segment cache. The present bit can therefore
have a subtly different meaning, and it is now cooked to uniformly indicate
whether the segment is usable or not.
GDTR and IDTR don't have access rights like the other segments, but for
consistency, they are treated as being present so no special casing is needed
elsewhere in the segmentation logic.
AMD hardware does not consider the present bit for %cs and %tr, and will
function as if they were present. They are therefore unconditionally set to
present when reading information from the VMCB, to maintain the new meaning of
usability.
Intel hardware has a separate unusable bit in the VMCS segment attributes.
This bit is inverted and stored in the present field, so the hvm code can work
with architecturally-common state.
This is XSA-191.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3666,6 +3666,10 @@ int hvm_virtual_to_linear_addr(
* COMPATIBILITY MODE: Apply segment checks and add base.
*/
+ /* Segment not valid for use (cooked meaning of .p)? */
+ if ( !reg->attr.fields.p )
+ return 0;
+
switch ( access_type )
{
case hvm_access_read:
@@ -3871,6 +3875,10 @@ static int hvm_load_segment_selector(
hvm_get_segment_register(
v, (sel & 4) ? x86_seg_ldtr : x86_seg_gdtr, &desctab);
+ /* Segment not valid for use (cooked meaning of .p)? */
+ if ( !desctab.attr.fields.p )
+ goto fail;
+
/* Check against descriptor table limit. */
if ( ((sel & 0xfff8) + 7) > desctab.limit )
goto fail;
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -620,6 +620,7 @@ static void svm_get_segment_register(str
{
case x86_seg_cs:
memcpy(reg, &vmcb->cs, sizeof(*reg));
+ reg->attr.fields.p = 1;
reg->attr.fields.g = reg->limit > 0xFFFFF;
break;
case x86_seg_ds:
@@ -653,13 +654,16 @@ static void svm_get_segment_register(str
case x86_seg_tr:
svm_sync_vmcb(v);
memcpy(reg, &vmcb->tr, sizeof(*reg));
+ reg->attr.fields.p = 1;
reg->attr.fields.type |= 0x2;
break;
case x86_seg_gdtr:
memcpy(reg, &vmcb->gdtr, sizeof(*reg));
+ reg->attr.bytes = 0x80;
break;
case x86_seg_idtr:
memcpy(reg, &vmcb->idtr, sizeof(*reg));
+ reg->attr.bytes = 0x80;
break;
case x86_seg_ldtr:
svm_sync_vmcb(v);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -867,10 +867,12 @@ void vmx_get_segment_register(struct vcp
reg->sel = sel;
reg->limit = limit;
- reg->attr.bytes = (attr & 0xff) | ((attr >> 4) & 0xf00);
- /* Unusable flag is folded into Present flag. */
- if ( attr & (1u<<16) )
- reg->attr.fields.p = 0;
+ /*
+ * Fold VT-x representation into Xen's representation. The Present bit is
+ * unconditionally set to the inverse of unusable.
+ */
+ reg->attr.bytes =
+ (!(attr & (1u << 16)) << 7) | (attr & 0x7f) | ((attr >> 4) & 0xf00);
/* Adjust for virtual 8086 mode */
if ( v->arch.hvm_vmx.vmx_realmode && seg <= x86_seg_tr
@@ -950,11 +952,11 @@ static void vmx_set_segment_register(str
}
}
- attr = ((attr & 0xf00) << 4) | (attr & 0xff);
-
- /* Not-present must mean unusable. */
- if ( !reg->attr.fields.p )
- attr |= (1u << 16);
+ /*
+ * Unfold Xen representation into VT-x representation. The unusable bit
+ * is unconditionally set to the inverse of present.
+ */
+ attr = (!(attr & (1u << 7)) << 16) | ((attr & 0xf00) << 4) | (attr & 0xff);
/* VMX has strict consistency requirement for flag G. */
attr |= !!(limit >> 20) << 15;
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1209,6 +1209,10 @@ protmode_load_seg(
&desctab, ctxt)) )
return rc;
+ /* Segment not valid for use (cooked meaning of .p)? */
+ if ( !desctab.attr.fields.p )
+ goto raise_exn;
+
/* Check against descriptor table limit. */
if ( ((sel & 0xfff8) + 7) > desctab.limit )
goto raise_exn;
[Attachment #5 (text/plain)]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
https://lists.xen.org/xen-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic