Xen 64-bit X86 PV Guest Top-Level Pagetable Write Arbitrary Entries

vendor:

Xen

by:

Project Zero

8,2

CVSS

HIGH

Xen 64-bit X86 PV Guest Top-Level Pagetable Write Arbitrary Entries

787

CWE

Product Name: Xen

Affected Version From: N/A

Affected Version To: N/A

Patch Exists: YES

Related CWE: N/A

CPE: N/A

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: N/A

2017

Xen 64-bit X86 PV Guest Top-Level Pagetable Write Arbitrary Entries

This vulnerability in Xen permits an attacker with control over the kernel of a 64bit X86 PV guest to write arbitrary entries into a live top-level pagetable. This is possible due to the fact that the arch.cr3 field in the vcpu struct does not take an extra type-specific reference, and instead borrows the reference from either arch.guest_table_user or arch.guest_table. This means that whenever the field from which the reference is borrowed is updated, arch.cr3 (together with the physical CR3) must be updated as well. The guest can update arch.guest_table_user and arch.guest_table using __HYPERVISOR_mmuext_op with commands MMUEXT_NEW_USER_BASEPTR and MMUEXT_NEW_BASEPTR. The handlers for these commands assume that when the hypercall is executed, arch.cr3 always equals arch.guest_table, however, using the __HYPERVISOR_multicall hypercall, it is possible to execute the __HYPERVISO_mmuext_op hypercall from user context.

Mitigation:

The vulnerability can be mitigated by ensuring that the arch.cr3 field in the vcpu struct takes an extra type-specific reference, and is not borrowing the reference from either arch.guest_table_user or arch.guest_table.

Source

Exploit-DB raw data:

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1231

This is a bug in Xen that permits an attacker with control over the
kernel of a 64bit X86 PV guest to write arbitrary entries into a live
top-level pagetable.

To prevent PV guests from doing things like mapping live pagetables as
writable, Xen assigns types to physical pages and tracks type-specific
references with a reference counter ("type count", stored in the low
bits of page->u.inuse.type_info).

64-bit PV guests have multiple places in which the addresses of
top-level pagetables are stored:

arch.guest_table_user and arch.guest_table in the vcpu struct point to
the pagetables the guest has designated as user-mode top-level
pagetable and kernel-mode top-level pagetable. Both of these fields
take a type-specific reference on the pagetable to prevent the guest
from mapping it as writable.

arch.cr3 in the vcpu struct points to the current top-level pagetable
of the vCPU. While the vCPU is scheduled, arch.cr3 is the same as the
physical CPU's CR3.
arch.cr3 does not take an extra type-specific reference; it borrows
the reference from either arch.guest_table_user or arch.guest_table.
This means that whenever the field from which the reference is
borrowed is updated, arch.cr3 (together with the physical CR3) must be
updated as well.

The guest can update arch.guest_table_user and arch.guest_table using
__HYPERVISOR_mmuext_op with commands
MMUEXT_NEW_USER_BASEPTR (for arch.guest_table_user) and
MMUEXT_NEW_BASEPTR (for arch.guest_table). The handlers for these
commands assume that when the hypercall is executed, arch.cr3 always
equals arch.guest_table: The MMUEXT_NEW_BASEPTR handler updates
arch.cr3 to the new arch.guest_table, the MMUEXT_NEW_USER_BASEPTR
handler doesn't touch arch.cr3.

Hypercalls can only be executed from kernel context, so on hypercall
entry, arch.cr3==arch.guest_table is indeed true. However, using the
__HYPERVISOR_multicall hypercall, it is possible to execute the
__HYPERVISOR_iret hypercall, which can switch the pagetables to user
context, immediately followed by the __HYPERVISOR_mmuext_op hypercall
before actually entering guest user context.


This can be exploited from guest kernel context roughly as follows:

 - copy all entries from the top-level kernel pagetable over the
   top-level user pagetable (to make it possible for a post-iret
   hypercall to access guest kernel memory)
 - allocate a new page to be used later as top-level user pagetable,
   copy the contents of the current top-level user pagetable into it,
   remap it as readonly and pin it as a top-level pagetable
 - perform the following operations in a single multicall:
  - switch to user context using __HYPERVISOR_iret
  - change arch.guest_table_user to the new top-level user pagetable
    using __HYPERVISOR_mmuext_op with command MMUEXT_NEW_USER_BASEPTR
 - unpin the old top-level user pagetable
 - map the old top-level user pagetable as writable
 - write crafted entries into the old top-level user pagetable


I have attached a proof of concept that corrupts the top-level
pagetable entry that maps the hypervisor text, causing a host
triplefault. I have tested the proof of concept in the following
configurations:

configuration 1:
running inside VMware Workstation
Xen version "Xen version 4.6.0 (Ubuntu 4.6.0-1ubuntu4.3)"
dom0: Ubuntu 16.04.2, Linux 4.8.0-41-generic #44~16.04.1-Ubuntu
unprivileged guest: Ubuntu 16.04.2, Linux 4.4.0-66-generic #87-Ubuntu

configuration 2:
running on a physical machine with Qubes OS 3.2 installed
Xen version 4.6.4

Compile the PoC with ./compile.sh, then run ./attack as root.

PoC Filename: xen_ptuaf.tar 

################################################################################

Here's an exploit that causes the hypervisor to execute shellcode that then deliberately causes a hypervisor GPF by calling a noncanonical address. Usage:

root@pv-guest:~/xen_ptuaf_hv_shellcode_exec# ./compile.sh                                                                                                                                                                                                                                                                  
make: Entering directory '/usr/src/linux-headers-4.4.0-66-generic'
  LD      /root/xen_ptuaf_hv_shellcode_exec/built-in.o
  CC [M]  /root/xen_ptuaf_hv_shellcode_exec/module.o
nasm -f elf64 -o /root/xen_ptuaf_hv_shellcode_exec/native.o /root/xen_ptuaf_hv_shellcode_exec/native.asm
  LD [M]  /root/xen_ptuaf_hv_shellcode_exec/test.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: could not find /root/xen_ptuaf_hv_shellcode_exec/.native.o.cmd for /root/xen_ptuaf_hv_shellcode_exec/native.o
  CC      /root/xen_ptuaf_hv_shellcode_exec/test.mod.o
  LD [M]  /root/xen_ptuaf_hv_shellcode_exec/test.ko
make: Leaving directory '/usr/src/linux-headers-4.4.0-66-generic'
root@pv-guest:~/xen_ptuaf_hv_shellcode_exec# ./attack                                                                                                                                                                                                                                                                      
kernel CR3: 0xaa2dd000
L1 self-mapping is up, should have reliable pagetable control now
virt_to_pte(0x7f5bd439a000)
[ rest of output missing because of VM crash ]


Serial output:

(XEN) ----[ Xen-4.6.0  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<00007f5bd439a03f>] 00007f5bd439a03f
(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d1v2)
(XEN) rax: 1337133713371337   rbx: 1337133713371337   rcx: 1337133713371337
(XEN) rdx: 1337133713371337   rsi: 00007ffe98b5e248   rdi: 0000600000003850
(XEN) rbp: 1337133713371337   rsp: ffff8301abb37f30   r8:  0000000000000000
(XEN) r9:  000000000000001b   r10: 0000000000000000   r11: 0000000000000202
(XEN) r12: 0000000080000000   r13: ffff8800026dd000   r14: ffff880003453c88
(XEN) r15: 0000000000000007   cr0: 0000000080050033   cr4: 00000000001506a0
(XEN) cr3: 00000000aa2dc000   cr2: ffff88007cfb2e98
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff8301abb37f30:
(XEN)    1337133713371337 1337133713371337 1337133713371337 1337133713371337
(XEN)    1337133713371337 1337133713371337 1337133713371337 1337133713371337
(XEN)    1337133713371337 1337133713371337 1337133713371337 1337133713371337
(XEN)    1337133713371337 0000000000401556 000000000000e033 0000000000000246
(XEN)    00007ffe98b5e208 000000000000e02b 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000002 ffff830088c9c000
(XEN)    000000312b835580 0000000000000000
(XEN) Xen call trace:
(XEN)    [<00007f5bd439a03f>] 00007f5bd439a03f
(XEN) 
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 2:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************
(XEN) 
(XEN) Reboot in five seconds...

PoC Filename: xen_ptuaf_hv_shellcode_exec.tar 


Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41973.zip