Xen Security Advisory 171 (CVE-2016-3157) - I/O port access privilege escalation in x86-64 Linux

Xen Security Advisory 171 (CVE-2016-3157) - I/O port access privilege escalation in x86-64 Linux

[Xen.org security team]

[-- Attachment #1: Type: text/plain, Size: 4895 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2016-3157 / XSA-171
                              version 4

         I/O port access privilege escalation in x86-64 Linux

UPDATES IN VERSION 4
====================

Clarify Vulnerable Systems section.

Public release.

ISSUE DESCRIPTION
=================

IRET and POPF do not modify EFLAGS.IOPL when executed by code at a
privilege level other than zero.  Since PV Xen guests run at privilege
level 3 (for 64-bit ones; 32-bit ones run at privilege level 1), to
compensate for this the context switching of EFLAGS.IOPL requires the
guest to make use of a dedicated hypercall (PHYSDEVOP_set_iopl).  The
invocation of this hypercall, while present in the 32-bit context
switch path, is missing from its 64-bit counterpart.

IMPACT
======

User mode processes not supposed to be able to access I/O ports may
be granted such permission, potentially resulting in one or more of
in-guest privilege escalation, guest crashes (Denial of Service), or
in-guest information leaks.

VULNERABLE SYSTEMS
==================

All upstream x86-64 Linux versions operating as PV Xen guests are
vulnerable.

ARM systems are not vulnerable.  x86 HVM guests are not vulnerable.
32-bit Linux guests are not vulnerable.

x86-64 Linux versions derived from linux-2.6.18-xen.hg (XenoLinux) are
not vulnerable.

We believe that non-Linux guests are not vulnerable, as we are not
aware of any with an analogous bug.

MITIGATION
==========

Running only HVM or 32-bit PV guests will avoid this issue.

CREDITS
=======

This issue was discovered by Andy Lutomirski.

RESOLUTION
==========

Applying the attached patch resolves this issue for the indicated Linux
versions.

xsa171.patch           Linux 4.5-rc7, Linux 4.4.x

$ sha256sum xsa171*
5d47ead1212c735b444ac8f82e7f311cda3473fe3847e576c3772ce020265dfd  xsa171.patch
$


DEPLOYMENT DURING EMBARGO
=========================

The patch is a change to the domU, ie, to the guest, not to hosts.


Where the guest kernel is provided by the host administrator
- ------------------------------------------------------------

Deployment of the patch by the host administrator 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 a the cloud guest administrator is almost certainly in
a position to see the changes that are made by to the kernel even if
the kernel is provided by the host administrator.

Deployment is permitted only AFTER the embargo ends.


Where the guest kernel is provided by the guest administrator
- -------------------------------------------------------------

Deployment of the patch (or another which is substantially similar) by
the guest administrator is permitted during the embargo ONLY if
 (i) the host administrator organisation is also a member of the Xen
     Project Security Issues Predisclosure List.
 (ii) all the guest's users are also members of predisclosure list.
     (guest users includes administrators of Linux containers running
     within the guest).

Restriction (i) is because the host administrator can see changes that
made to the kernel by a guest administrator.  Restriction (ii) is
because it is difficult to fully conceal the Linux kernel from
unprivileged guest user processes.

If the host is not operated by a member of the predisclosure list, or
the guest has users outside the predisclousre list, deployment is
permitted only AFTER the embargo ends.


In any case
- -----------

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, or whose situation is not clearly covered
above, 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)

iQEcBAEBAgAGBQJW6a4ZAAoJEIP+FMlX6CvZEs4H/12hKU3NzqfHZb/wOW9PeT4Z
yhGQ2mkVE6FATW15b+/+Lr4N2nIUHa40BtWjPyEOQR4UXJrZr3R5HL/wINRO7c6M
5XNjDyHqmfhOAsHWsrTB0a3CP2wWNNQ6LiBN5AuiUwoqiJiZPLhKCeEi99F+rFFK
IINyOgd4XSeGRkb96GfZcPbizbO3wqiREfBIAjECYchBARv7JVGr3my6R3YBYdTn
VtBratEPdkEmAEn0LtdiQlnjPib5O3paiaIDk41IPbPu1WPiozt3RJSqJUSwu+al
A3qe9cBGz0NyghdYkXQjvaPP+1Q3BjyJC4hgGLo+yqyODPdaFAJZ0mjR/e0uajs=
=F9Nz
-----END PGP SIGNATURE-----

[-- Attachment #2: xsa171.patch --]
[-- Type: application/octet-stream, Size: 2095 bytes --]

From: Andy Lutomirski <luto@kernel.org>

x86/iopl/64: properly context-switch IOPL on Xen PV

On Xen PV, regs->flags doesn't reliably reflect IOPL and the
exit-to-userspace code doesn't change IOPL.  We need to context
switch it manually.

I'm doing this without going through paravirt because this is
specific to Xen PV.  After the dust settles, we can merge this with
the 32-bit code, tidy up the iopl syscall implementation, and remove
the set_iopl pvop entirely.

This is XSA-171.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org 
Reviewed-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -62,4 +62,6 @@ void xen_arch_register_cpu(int num);
 void xen_arch_unregister_cpu(int num);
 #endif
 
+void xen_set_iopl_mask(unsigned mask);
+
 #endif /* _ASM_X86_XEN_HYPERVISOR_H */
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -48,6 +48,7 @@
 #include <asm/syscalls.h>
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
+#include <asm/xen/hypervisor.h>
 
 asmlinkage extern void ret_from_fork(void);
 
@@ -411,6 +412,17 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
 		     task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
 		__switch_to_xtra(prev_p, next_p, tss);
 
+#ifdef CONFIG_XEN
+	/*
+	 * On Xen PV, IOPL bits in pt_regs->flags have no effect, and
+	 * current_pt_regs()->flags may not match the current task's
+	 * intended IOPL.  We need to switch it manually.
+	 */
+	if (unlikely(static_cpu_has(X86_FEATURE_XENPV) &&
+		     prev->iopl != next->iopl))
+		xen_set_iopl_mask(next->iopl);
+#endif
+
 	if (static_cpu_has_bug(X86_BUG_SYSRET_SS_ATTRS)) {
 		/*
 		 * AMD CPUs have a misfeature: SYSRET sets the SS selector but
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -961,7 +961,7 @@ static void xen_load_sp0(struct tss_struct *tss,
 	tss->x86_tss.sp0 = thread->sp0;
 }
 
-static void xen_set_iopl_mask(unsigned mask)
+void xen_set_iopl_mask(unsigned mask)
 {
 	struct physdev_set_iopl set_iopl;
 

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel