.
Xen Security Advisory XSA-134 GNTTABOP_swap_grant_ref operation misbehavior *** EMBARGOED UNTIL 2015-06-11 12:00 UTC *** ISSUE DESCRIPTION ================= With the introduction of version 2 grant table operations, a version check became necessary for most grant table related hypercalls. The GNTTABOP_swap_grant_ref call was lacking such a check. As a result, the subsequent code behaved as if version 2 was in use, when a guest issued this hypercall without a prior GNTTABOP_setup_table or GNTTABOP_set_version. The effect is a possible NULL pointer dereferences. However, this cannot be exploited to elevate privileges of the attacking domain, as the maximum memory address that can be wrongly accessed this way is bounded to far below the start of hypervisor memory. IMPACT ====== Malicious or buggy guest domain kernels can mount a denial of service attack which, if successful, can affect the whole system. VULNERABLE SYSTEMS ================== Xen versions from 4.2 onwards are vulnerable. MITIGATION ========== There is no mitigation available. RESOLUTION ========== Applying the attached patch resolves this issue. xsa134.patch xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x $ sha256sum xsa134*.patch dff7f39a85f799c8b017a748b9b5cc7961daa010813e71683c1dccf93d91f1ee xsa134.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 ______________________________ Xen Security Advisory CVE-2015-3209 / XSA-135 version 2 Heap overflow in QEMU PCNET controller, allowing guest->host escape *** EMBARGOED UNTIL 2015-06-10 14:00 UTC *** UPDATES IN VERSION 2 ==================== Patches converted to Unix line endings and made compatible with git am. ISSUE DESCRIPTION ================= The QEMU security team has predisclosed the following advisory: pcnet_transmit loads a transmit-frame descriptor from the guest into the /tmd/ local variable to recover a length field, a status field and a guest-physical location of the associated frame buffer. If the status field indicates that the frame buffer is ready to be sent out (i.e. by setting the TXSTATUS_DEVICEOWNS, TXSTATUS_STARTPACKET and TXSTATUS_ENDPACKET bits on the status field), the PCNET device controller pulls in the frame from the guest-physical location to s->buffer (which is 4096 bytes long), and then transmits the frame. Because of the layout of the transmit-frame descriptor, it is not possible to send the PCNET device controller a frame of length > 4096, but it /is/ possible to send the PCNET device controller a frame that is marked as TXSTATUS_STARTPACKET, but not TXSTATUS_ENDPACKET. If we do this - and the PCNET controller is configured via the XMTRL CSR to support split-frame processing - then the pcnet_transmit functions loops round, pulling a second transmit frame descriptor from the guest. If this second transmit frame descriptor sets the TXSTATUS_DEVICEOWNS and doesn't set the TXSTATUS_STARTPACKET bits, this frame is appended to the s->buffer field. An attacker can then exploit this vulnerability by sending a first packet of length 4096 to the device controller, and a second frame containing N-bytes to trigger an N-byte heap overflow. On 64-bit QEMU, a 24-byte overflow allows the guest to take control of the phys_mem_write function pointer in the PCNetState_st structure, and this is called when trying to flush the updated transmit frame descriptor back to the guest. By specifying the content of the second transmit frame, the attacker therefore gets reliable fully-chosen control of the host instruction pointer, allowing them to take control of the host. IMPACT ====== A guest which has access to an emulated PCNET network device (e.g. with "model=pcnet" in their VIF configuration) can exploit this vulnerability to take over the qemu process elevating its privilege to that of the qemu process. VULNERABLE SYSTEMS ================== All Xen systems running x86 HVM guests without stubdomains which have been configured to use the PCNET emulated driver model are vulnerable. The default configuration is NOT vulnerable (because it does not emulate PCNET NICs). Systems running only PV guests are NOT vulnerable. Systems using qemu-dm stubdomain device models (for example, by specifying "device_model_stubdomain_override=1" in xl's domain configuration files) are NOT vulnerable. Both the traditional "qemu-xen" or upstream qemu device models are potentially vulnerable. ARM systems are NOT vulnerable. MITIGATION ========== Avoiding the use of emulated network devices altogether, by specifying a PV only VIF in the domain configuration file will avoid this issue. Avoiding the use of the PCNET device in favour of other emulations will also avoid this issue. Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. qemu-dm stubdomains are only available with the traditional "qemu-xen" version. RESOLUTION ========== Applying the appropriate attached patch(es) resolves this issue. xsa135-qemuu-unstable.patch qemu-upstream, Xen unstable xsa135-qemuu-4.5-*.patch qemu-upstream, Xen 4.5.x, Xen 4.4.x xsa135-qemuu-4.3-*.patch qemu-upstream, Xen 4.3.x xsa135-qemuu-4.2-*.patch qemu-upstream, Xen 4.2.x xsa135-qemut-*.patch qemu-xen-traditional, Xen unstable, 4.5.x, 4.4.x, 4.3.x, 4.2.x Note that the second patch for qemu-xen-traditional (all versions), and qemu-upstream 4.3.x and 4.2.x are identical. Likewise xsa135-qemuu-unstable.patch is the same as xsa135-qemuu-4.5-2.patch. They are presented separately for convenience. $ sha256sum xsa135*.patch a40897166f5de84c11b5d547191cd0375c7052edb0f44940eec7b78d839e447b xsa135-qemut-1.patch d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091 xsa135-qemut-2.patch 099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da xsa135-qemuu-unstable.patch 12ca5521f6bb1227934a1711d8adee11138a84c080a217f250efe34b3cb25b10 xsa135-qemuu-4.2-1.patch d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091 xsa135-qemuu-4.2-2.patch ad32c0ac145bc02b901c061fcbef83965f443fe89fcae9efc3b1dfd1e1d70bc8 xsa135-qemuu-4.3-1.patch d98452d4c42fae1f11e887537a4638694de8a4bf00835daac6e51801297e4091 xsa135-qemuu-4.3-2.patch baf9e0a960693b246ff01bb6210c5fee7713999d1e1b00a5b4e29d9ebd3c0ce8 xsa135-qemuu-4.5-1.patch 099693483d468a7fdecbf825635d3595ebeecc91c496624cbe109dcb4dd235da xsa135-qemuu-4.5-2.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of patches or mitigations is NOT permitted (except on systems used and administered only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. The decision not to permit deployment was made by the group that, at their discretion, disclosed the issue to the Xen Project Security Team. Deployment is permitted only AFTER the embargo ends. (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
Email with the patches has been sent via PGP to dlan@gentoo.org.
Sorry, I should've checked whether a bug already existed before doing anything so I've made dupes on bug 550672 and bug 550674. The reason I split it is the difference in announcement dates (135 is 10th and 134 is 11th). Which should we keep?
(In reply to Kristian Fiskerstrand from comment #3) > Sorry, I should've checked whether a bug already existed before doing > anything so I've made dupes on bug 550672 and bug 550674. The reason I split > it is the difference in announcement dates (135 is 10th and 134 is 11th). > > Which should we keep? I rolled them up because Sept 11th is the more serious one, and based on this, dlan will probably call for stabilization only one time.
*** Bug 550674 has been marked as a duplicate of this bug. ***
*** Bug 550672 has been marked as a duplicate of this bug. ***
Xen Security Advisory XSA-136 vulnerability in the iret hypercall handler *** EMBARGOED UNTIL 2015-06-11 12:00 UTC *** ISSUE DESCRIPTION ================= A buggy loop in Xen's compat_iret() function iterates the wrong way around a 32-bit index. Any 32-bit PV guest kernel can trigger this vulnerability by attempting a hypercall_iret with EFLAGS.VM set. Given the use of __get/put_user(), and that the virtual addresses in question are contained within the lower canonical half, the guest cannot clobber any hypervisor data. Instead, Xen will take up to 2^33 pagefaults, in sequence, effectively hanging the host. IMPACT ====== Malicious guest administrators can cause a denial of service affecting the whole system.
All issues are now public
Arches, please test and mark stable: =app-emulation/xen-4.2.5-r11 =app-emulation/xen-tools-4.2.5-r7 Target keywords Both : "amd64 x86" =app-emulation/xen-4.5.0-r8 =app-emulation/xen-tools-4.5.0-r6 Target keywords Only: "amd64" patches of XSA-134,136 in app-emulation/xen patches of XSA-135 in app-emulation/xen-tools
CVE-2015-3209 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-3209): Heap-based buffer overflow in the PCNET controller in QEMU allows remote attackers to execute arbitrary code by sending a packet with TXSTATUS_STARTPACKET set and then a crafted packet with TXSTATUS_DEVICEOWNS set.
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
CVE-2015-4164 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-4164): The compat_iret function in Xen 3.1 through 4.5 iterates the wrong way through a loop, which allows local 32-bit PV guest administrators to cause a denial of service (large loop and system hang) via a hypercall_iret call with EFLAGS.VM set. CVE-2015-4163 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-4163): GNTTABOP_swap_grant_ref in Xen 4.2 through 4.5 does not check the grant table operation version, which allows local guest domains to cause a denial of service (NULL pointer dereference) via a hypercall without a GNTTABOP_setup_table or GNTTABOP_set_version.
Arches and Maintainer(s), Thank you for your work. Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201604-03 at https://security.gentoo.org/glsa/201604-03 by GLSA coordinator Yury German (BlueKnight).
