Critical vulnerability in the Xen hypervisor

The critical elevation privilege vulnerability has been corrected in the hypervisor Xen. This gap allows to gain control over the host server. Seven years this problem is present in the Xen code base.

The developers of the Xen hypervisor released nine security patches, eliminating multiple vulnerabilities in the server software. One of the flaws could allow an attacker to gain control over the host server. We are talking about the vulnerability CVE-2015-7835 (XSA-148), by which the paravirtualization guest can manage memory OS of the host and other virtual machines. The problem was discovered by engineers Alibaba, which recently joined the development of Xen.

The vulnerability is due to the fact that in the MMU code for x86 version of Xen there is the following line:

if (unlikely (l2e_get_flags (nl2e) & L2_DISALLOW_MASK)) L2_DISALLOW_MASK defined as: #define L2_DISALLOW_MASK (base_disallow_mask & ~ _PAGE_PSE) base_disallow_mask defined as: base_disallow_mask = ~ (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_AVAIL);

According to the developers of the operating system Qubes, this problem is the most dangerous vulnerability in Xen Project’s history. An attacker can bypass security checks and gain the right to read and write to the memory of the host server, and also compromise all virtual operating systems on target system.

The vulnerability is manifested in Xen 3.4 (32-bit and 64-bit x86 systems) and newer releases (ARM systems are not susceptible). We recommended all users of Xen to apply the patch or install updates as soon as possible (currently available only for Qubes OS: 4.4.3-8 and 4.1.6.1-23 packages). Another option is to run paravirtualized operating systems in full virtualization mode (HVM). Amazon has announced that its cloud services are not affected by this issue. Rackspace, IBM / Softlayer and Linode also already fixed this problem before its public disclosure.

The developers also eliminated 8 denial of service vulnerabilities affecting x86- and ARM-version of Xen. A remote user can use these flaws to carry out DoS-attacks.

Multiple vulnerabilities in Xen

Danger: High

Availability of correction: Yes

The number of vulnerabilities: 9

CVE ID:

#1 CVE-2015-7812 (XSA-145)

#2 CVE-2015-7813 (XSA-146)

#3 CVE-2015-7814 (XSA-147) #4 CVE-2015-7835 (XSA-148)

#5 CVE-2015-7969 (XSA-149)

#6 CVE-2015-7970 (XSA-150) #7 CVE-2015-7969 (XSA-151)

#8 CVE-2015-7971 (XSA-152)

#9 CVE-2015-7972 (XSA-153)

Vector of operation: Remote

Impact: DoS-attack, Privilege escalation

Affected versions: Xen 4.4.x and later

Description:

#1 CVE-2015-7812 – Host crash when preempting a multicall. The vulnerability is caused due to an error in the multicall functional. A remote user can cause denial of service.

#2 CVE-2015-7813 – various unimplemented hypercalls log without rate limiting. A vulnerability is caused due to an error in hypercall HYPERVISOR_physdev_op. A remote user can cause denial of service.

#3 CVE-2015-7814 – Race between domain destruction and memory allocation decrease. A vulnerability is caused due to an error in XENMEM_decrease_reservation. A remote user can cause denial of service.

Note: Vulnerabilities #1 – #3 affects only ARM-systems.

#4 CVE-2015-7835 – Uncontrolled creation of large page mappings by PV guests. The vulnerability is caused due to an error bypass security restrictions in validator table entries 2 level. This can be exploited to elevate privileges.

#5 – #9 This vulnerabilities is caused due to errors in the following components:

#5 [CVE-2015-7969] XEN_DOMCTL_max_vcpus;

#6 [CVE-2015-7970] Mode Populate-on-Demand;

#7 [CVE-2015-7969] hypercall XENOPROF_get_buffer;

#8 [CVE-2015-7971] HYPERCALL_xenoprof_op and HYPERVISOR_xenpmu_op;

#9 [CVE-2015-7972] mode Populate-on-Demand.

This can be exploited to carry out DoS-attacks.

Note: Vulnerabilities #4 – #9 affects only x86 systems.

Links:

http://lists.xenproject.org/archives/html/xen-announce/2015-10/

http://lists.xenproject.org/archives/html/xen-announce/2015-10/msg00003.html