Xen Security Advisory XSA-139 Use after free in QEMU/Xen block unplug protocol *** EMBARGOED UNTIL 2015-08-03 12:00 UTC *** ISSUE DESCRIPTION ================= When unplugging an emulated block device the device was not fully unplugged, meaning a second unplug attempt would attempt to unplug the device a second time using a previously freed pointer. IMPACT ====== An HVM guest which has access to an emulated IDE disk device may be able to exploit this vulnerability in order to take over the qemu process elevating its privilege to that of the qemu process. VULNERABLE SYSTEMS ================== All Xen systems running x86 HVM guests using the upstream based "qemu-xen" are vulnerable. Systems using the "qemu-xen-traditional" version of the qemu device model, either in a stubdomain or as a domain 0 process, are not vulnerable. Systems running only PV guests are NOT vulnerable. ARM systems are not vulnerable. MITIGATION ========== There is no known mitigation for this issue. RESOLUTION ========== The attached patches have been proposed as fixes for the issue. They have not been fully reviewed and tested. We are sending them out now because there are less than 2 weeks left until the embargo is lifted. Please send review comments and test reports of the patches to xen-security-issues-discuss@lists.xenproject.org. xsa139-qemuu-unstable.patch qemu-upstream, xen-unstable xsa139-qemuu-4.5.patch qemu-upstream, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x $ sha256sum xsa139*.patch dead84667dd4868d0688dc4e62a54a14883e6f0352cf3318b277aa37e27c9261 xsa139-qemuu-unstable.patch 3aa775255053d1d14a3e383998240eb3520aea7de137cdb7624b169db8b06d85 xsa139-qemuu-4.5.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 XSA-140 QEMU leak of uninitialized heap memory in rtl8139 device model *** EMBARGOED UNTIL 2015-08-03 12:00 UTC *** ISSUE DESCRIPTION ================= The QEMU model of the RTL8139 network card did not sufficiently validate inputs in the C+ mode offload emulation. This results in uninitialised memory from the QEMU process's heap being leaked to the domain as well as to the network. IMPACT ====== A guest may be able to read sensitive host-level data relating to itself which resides in the QEMU process. Such information may include things such as information relating to real devices backing emulated devices or passwords which the host administrator does not intend to share with the guest admin. VULNERABLE SYSTEMS ================== All Xen systems running x86 HVM guests without stubdomains which have been configured with an emulated RTL8139 driver model (which is the default) are 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-traditional") or upstream-based ("qemu-xen") qemu device models are potentially vulnerable. Systems running only PV guests are NOT vulnerable. ARM systems are NOT vulnerable. QEMU-XEN-TRADITIONAL ==================== The patches supplied by the Qemu Project are of course against recent versions of qemu. They cannot be applied directly to qemu-xen-traditional. The Xen Project Security Team do not feel we have the resources to backport and qualify these substantial and intrusive patches. Users using qemu-xen-traditional with stub domains are not vulnerable, because the stub dm is a deprivileged qemu guest instance. Users using qemu-xen-traditional for compatibility with old guests can avoid the vulnerability by switching to using a stub device model. The Xen Project Security Team encourages users and downstreams who are using qemu-xen-traditional and able to backport the patches to share those patches with us, so that we may distribute them with an updated advisory. We will encourage the community to have a conversation, when this advisory is released, about the continuing security support status of qemu-xen-traditional in non-stub-dm configurations. 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 RTL8139 device in favour of other emulations will also avoid this issue. Enabling stubdomains will mitigate this issue, by reducing the information leak to only information belonging to the service domain. qemu-dm stubdomains are only available with the "qemu-xen-traditional" device model version. RESOLUTION ========== The attached patches have been proposed as fixes for the issue. They have not been fully reviewed and tested. We are sending them out now because there are less than 2 weeks left until the embargo is lifted. Please send review comments and test reports of the patches to xen-security-issues-discuss@lists.xenproject.org. xsa140-qemuu-unstable-?.patch qemu-upstream, xen-unstable, Xen 4.5.x, Xen 4.4.x xsa140-qemuu-4.3-?.patch qemu-upstream, Xen 4.3.x, Xen 4.2.x $ sha256sum xsa140*.patch 12d0dc1a31449288ed5e562a1e9415c437b7a2799e8afa0b251e3957a0d8ab23 xsa140-qemuu-unstable-1.patch c91a60b7d7e18ea95b31eca0ba940d53c14730fae1e50802375c9e5ab7d0f109 xsa140-qemuu-unstable-2.patch 99062a9cbf4b96de8f0aa8555291cf6e296a9dbdf22ad4e9285912ba02de9261 xsa140-qemuu-unstable-3.patch 82d2214a0bd42b03b72b26170e4c80699d74bc691b6e223780a693ad2e9c267a xsa140-qemuu-unstable-4.patch b728ae69e4a1d838bb1b4c5e6135e84fe8f6fc7e97fdc99915e7fc908edb4fd2 xsa140-qemuu-unstable-5.patch 6fb23646e05ef9a4b010d2a2c0235b6ee58a293f39ed40b6b1611115c948a79a xsa140-qemuu-unstable-6.patch ebcadb69110ea4672795b52472222ed1ffe67a83e37c5b7d401530f43137c587 xsa140-qemuu-unstable-7.patch f33046ad9f29878a6d6cc7fbd5f58959b26aa1f5fb5be3ff0c933a11d7ed51d8 xsa140-qemuu-4.3-1.patch 2d43b2de5152623d8beb4e304330c09bc6bd338343e4398d74ae256623d00007 xsa140-qemuu-4.3-2.patch 54a9d5b64e3562ba68a68178a292a125ca7c73edd24ec4fc3cb5908728ff75c9 xsa140-qemuu-4.3-3.patch b803887acb91ae52c90ef478068bd588e06c84a4ef4b92a8bfb776b79ac8f318 xsa140-qemuu-4.3-4.patch bb4130ae38ca515e76dcac0fcb895d2e8780bab75576096372292d1707d3134e xsa140-qemuu-4.3-5.patch e1acc11ef537c747c118da758cf160d738576ff9efce950eed3c71c889f843f4 xsa140-qemuu-4.3-6.patch 6fabe8336e8d847366d51670b356c70a994eaf286733043209ef9ac51d67384c xsa140-qemuu-4.3-7.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches 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: Deployment of any of the mitigations described above 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. This is because in all cases the configuration change may be visible to the guest. Also, 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
patches have been sent to dlan by mail. This affects qemu as well, cardoe, please confirm that you have read and understood the deployment during embargo and security policies.
(In reply to Kristian Fiskerstrand from comment #1) > patches have been sent to dlan by mail. > > This affects qemu as well, cardoe, please confirm that you have read and > understood the deployment during embargo and security policies. ... if you want me to send you the patches by email, that is
(In reply to Kristian Fiskerstrand from comment #1) > patches have been sent to dlan by mail. > > This affects qemu as well, cardoe, please confirm that you have read and > understood the deployment during embargo and security policies. ACK. I agree to them and understand them.
Issue is now public
qemu-2.3.0-r5 is in the tree note: we should also stabilize qemu-guest-agent-2.3.0 too to keep in sync
+*xen-tools-4.5.1-r3 (05 Aug 2015) +*xen-tools-4.2.5-r10 (05 Aug 2015) + + 05 Aug 2015; Yixun Lan <dlan@gentoo.org> +xen-tools-4.2.5-r10.ebuild, + +xen-tools-4.5.1-r3.ebuild: + security bump, bug 556304, fix XSA139,140 Arches, please test and mark stable: =app-emulation/xen-tools-4.2.5-r10 Target keywords Both : "amd64 x86" =app-emulation/xen-tools-4.5.1-r3 Target keywords Only: "amd64"
Marked stable. Added to existing glsa draft
+ 06 Aug 2015; Yixun Lan <dlan@gentoo.org> -xen-tools-4.2.5-r9.ebuild, + -xen-tools-4.5.1-r2.ebuild: + cleanup old vulnerable versions, bug 556304
Added to existing GLSA.
This issue was resolved and addressed in GLSA 201604-03 at https://security.gentoo.org/glsa/201604-03 by GLSA coordinator Yury German (BlueKnight).