From: Xen.org security team <security@xen.org>
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
xen-users@lists.xen.org, oss-security@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Subject: Xen Security Advisory 193 (CVE-2016-9385) - x86 segment base write emulation lacking canonical address checks
Date: Tue, 22 Nov 2016 12:02:22 +0000 [thread overview]
Message-ID: <E1c99mI-00086a-9W@xenbits.xenproject.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2016-9385 / XSA-193
version 3
x86 segment base write emulation lacking canonical address checks
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
Both writes to the FS and GS register base MSRs as well as the
WRFSBASE and WRGSBASE instructions require their input values to be
canonical, or a #GP fault will be raised. When the use of those
instructions by the hypervisor was enabled, the previous guard against
#GP faults (having recovery code attached) was accidentally removed.
IMPACT
======
A malicious guest administrator can crash the host, leading to a DoS.
VULNERABLE SYSTEMS
==================
Xen versions 4.4 and onwards are affected. Xen versions 4.3 and
earlier are not affected.
The vulnerability is only exposed to x86 PV guests.
The vulnerability is NOT exposed to x86 HVM guests.
ARM systems are NOT vulnerable.
MITIGATION
==========
Running only HVM guests will avoid this vulnerability.
For PV guests the vulnerability can be avoided if the guest kernel is
controlled by the host rather than guest administrator, provided that
further steps are taken to prevent the guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa193.patch xen-unstable
xsa193-4.7.patch Xen 4.7.x, Xen 4.6.x
xsa193-4.5.patch Xen 4.5.x, Xen 4.4.x
$ sha256sum xsa193*
401df29b462a3430403a4f5bb36fd7824e692c9b5bac650e1a9d70bd440a55a1 xsa193.patch
b3494b1fe5fefc0d032bd603340e364c880ec0d3ae3fb8aa3a773038e956f955 xsa193-4.5.patch
f1b0092c585ebffe83d6ed7df94885ec5dfcb4227bdb33f421bad9febb8135a1 xsa193-4.7.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
iQEcBAEBAgAGBQJYNDK2AAoJEIP+FMlX6CvZswsIAI17sWqaGeP8GvtddxR08G2J
3Nb7Lnb/4cq8Hdc5XmUnX/zuDqobT5AGJEgKAuhRc9zs2TOv8FwcABc+/odKG6ak
tcMAaLThMcKbB0b0ZYEkcrU+jaCDDVE3rYVGjKv0hHKZNRY/SmWOdl180xcHksXG
pj5OQn6/+db6nqMlhyOcOyjM3w1/1AUe/O0EDsdUSNrY1mZi4/MjUXlDaJTZbDCc
KW9XUeRSq66iZELawBaosViTenOm/R+8DJGiR8fmJlXx+gzpEywtsEUCrxeKlTDo
tT68gwy0aHdlqKbIthkKr5qaT5FtKPyX0UpIXu7qtldbdEZG61iIlNOEG8tyPhU=
=fjbt
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa193.patch --]
[-- Type: application/octet-stream, Size: 2798 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86/PV: writes of %fs and %gs base MSRs require canonical addresses
Commit c42494acb2 ("x86: fix FS/GS base handling when using the
fsgsbase feature") replaced the use of wrmsr_safe() on these paths
without recognizing that wr{f,g}sbase() use just wrmsrl() and that the
WR{F,G}SBASE instructions also raise #GP for non-canonical input.
Similarly arch_set_info_guest() needs to prevent non-canonical
addresses from getting stored into state later to be loaded by context
switch code. For consistency also check stack pointers and LDT base.
DR0..3, otoh, already get properly checked in set_debugreg() (albeit
we discard the error there).
The SHADOW_GS_BASE check isn't strictly necessary, but I think we
better avoid trying the WRMSR if we know it's going to fail.
This is XSA-193.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -897,7 +897,13 @@ int arch_set_info_guest(
{
if ( !compat )
{
- if ( !is_canonical_address(c.nat->user_regs.eip) ||
+ if ( !is_canonical_address(c.nat->user_regs.rip) ||
+ !is_canonical_address(c.nat->user_regs.rsp) ||
+ !is_canonical_address(c.nat->kernel_sp) ||
+ (c.nat->ldt_ents && !is_canonical_address(c.nat->ldt_base)) ||
+ !is_canonical_address(c.nat->fs_base) ||
+ !is_canonical_address(c.nat->gs_base_kernel) ||
+ !is_canonical_address(c.nat->gs_base_user) ||
!is_canonical_address(c.nat->event_callback_eip) ||
!is_canonical_address(c.nat->syscall_callback_eip) ||
!is_canonical_address(c.nat->failsafe_callback_eip) )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2560,21 +2560,21 @@ static int priv_op_write_msr(unsigned in
int rc;
case MSR_FS_BASE:
- if ( is_pv_32bit_domain(currd) )
+ if ( is_pv_32bit_domain(currd) || !is_canonical_address(val) )
break;
wrfsbase(val);
curr->arch.pv_vcpu.fs_base = val;
return X86EMUL_OKAY;
case MSR_GS_BASE:
- if ( is_pv_32bit_domain(currd) )
+ if ( is_pv_32bit_domain(currd) || !is_canonical_address(val) )
break;
wrgsbase(val);
curr->arch.pv_vcpu.gs_base_kernel = val;
return X86EMUL_OKAY;
case MSR_SHADOW_GS_BASE:
- if ( is_pv_32bit_domain(currd) ||
+ if ( is_pv_32bit_domain(currd) || !is_canonical_address(val) ||
wrmsr_safe(MSR_SHADOW_GS_BASE, val) )
break;
curr->arch.pv_vcpu.gs_base_user = val;
[-- Attachment #3: xsa193-4.5.patch --]
[-- Type: application/octet-stream, Size: 2886 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86/PV: writes of %fs and %gs base MSRs require canonical addresses
Commit c42494acb2 ("x86: fix FS/GS base handling when using the
fsgsbase feature") replaced the use of wrmsr_safe() on these paths
without recognizing that wr{f,g}sbase() use just wrmsrl() and that the
WR{F,G}SBASE instructions also raise #GP for non-canonical input.
Similarly arch_set_info_guest() needs to prevent non-canonical
addresses from getting stored into state later to be loaded by context
switch code. For consistency also check stack pointers and LDT base.
DR0..3, otoh, already get properly checked in set_debugreg() (albeit
we discard the error there).
The SHADOW_GS_BASE check isn't strictly necessary, but I think we
better avoid trying the WRMSR if we know it's going to fail.
This is XSA-193.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -741,7 +741,13 @@ int arch_set_info_guest(
{
if ( !compat )
{
- if ( !is_canonical_address(c.nat->user_regs.eip) ||
+ if ( !is_canonical_address(c.nat->user_regs.rip) ||
+ !is_canonical_address(c.nat->user_regs.rsp) ||
+ !is_canonical_address(c.nat->kernel_sp) ||
+ (c.nat->ldt_ents && !is_canonical_address(c.nat->ldt_base)) ||
+ !is_canonical_address(c.nat->fs_base) ||
+ !is_canonical_address(c.nat->gs_base_kernel) ||
+ !is_canonical_address(c.nat->gs_base_user) ||
!is_canonical_address(c.nat->event_callback_eip) ||
!is_canonical_address(c.nat->syscall_callback_eip) ||
!is_canonical_address(c.nat->failsafe_callback_eip) )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2439,19 +2439,19 @@ static int emulate_privileged_op(struct
switch ( (u32)regs->ecx )
{
case MSR_FS_BASE:
- if ( is_pv_32on64_vcpu(v) )
+ if ( is_pv_32on64_vcpu(v) || !is_canonical_address(msr_content) )
goto fail;
wrfsbase(msr_content);
v->arch.pv_vcpu.fs_base = msr_content;
break;
case MSR_GS_BASE:
- if ( is_pv_32on64_vcpu(v) )
+ if ( is_pv_32on64_vcpu(v) || !is_canonical_address(msr_content) )
goto fail;
wrgsbase(msr_content);
v->arch.pv_vcpu.gs_base_kernel = msr_content;
break;
case MSR_SHADOW_GS_BASE:
- if ( is_pv_32on64_vcpu(v) )
+ if ( is_pv_32on64_vcpu(v) || !is_canonical_address(msr_content) )
goto fail;
if ( wrmsr_safe(MSR_SHADOW_GS_BASE, msr_content) )
goto fail;
[-- Attachment #4: xsa193-4.7.patch --]
[-- Type: application/octet-stream, Size: 2966 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86/PV: writes of %fs and %gs base MSRs require canonical addresses
Commit c42494acb2 ("x86: fix FS/GS base handling when using the
fsgsbase feature") replaced the use of wrmsr_safe() on these paths
without recognizing that wr{f,g}sbase() use just wrmsrl() and that the
WR{F,G}SBASE instructions also raise #GP for non-canonical input.
Similarly arch_set_info_guest() needs to prevent non-canonical
addresses from getting stored into state later to be loaded by context
switch code. For consistency also check stack pointers and LDT base.
DR0..3, otoh, already get properly checked in set_debugreg() (albeit
we discard the error there).
The SHADOW_GS_BASE check isn't strictly necessary, but I think we
better avoid trying the WRMSR if we know it's going to fail.
This is XSA-193.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -890,7 +890,13 @@ int arch_set_info_guest(
{
if ( !compat )
{
- if ( !is_canonical_address(c.nat->user_regs.eip) ||
+ if ( !is_canonical_address(c.nat->user_regs.rip) ||
+ !is_canonical_address(c.nat->user_regs.rsp) ||
+ !is_canonical_address(c.nat->kernel_sp) ||
+ (c.nat->ldt_ents && !is_canonical_address(c.nat->ldt_base)) ||
+ !is_canonical_address(c.nat->fs_base) ||
+ !is_canonical_address(c.nat->gs_base_kernel) ||
+ !is_canonical_address(c.nat->gs_base_user) ||
!is_canonical_address(c.nat->event_callback_eip) ||
!is_canonical_address(c.nat->syscall_callback_eip) ||
!is_canonical_address(c.nat->failsafe_callback_eip) )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2723,19 +2723,22 @@ static int emulate_privileged_op(struct
switch ( regs->_ecx )
{
case MSR_FS_BASE:
- if ( is_pv_32bit_domain(currd) )
+ if ( is_pv_32bit_domain(currd) ||
+ !is_canonical_address(msr_content) )
goto fail;
wrfsbase(msr_content);
v->arch.pv_vcpu.fs_base = msr_content;
break;
case MSR_GS_BASE:
- if ( is_pv_32bit_domain(currd) )
+ if ( is_pv_32bit_domain(currd) ||
+ !is_canonical_address(msr_content) )
goto fail;
wrgsbase(msr_content);
v->arch.pv_vcpu.gs_base_kernel = msr_content;
break;
case MSR_SHADOW_GS_BASE:
- if ( is_pv_32bit_domain(currd) )
+ if ( is_pv_32bit_domain(currd) ||
+ !is_canonical_address(msr_content) )
goto fail;
if ( wrmsr_safe(MSR_SHADOW_GS_BASE, msr_content) )
goto fail;
[-- Attachment #5: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
reply other threads:[~2016-11-22 12:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1c99mI-00086a-9W@xenbits.xenproject.org \
--to=security@xen.org \
--cc=oss-security@lists.openwall.com \
--cc=xen-announce@lists.xen.org \
--cc=xen-devel@lists.xen.org \
--cc=xen-users@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).