-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2015-5165 / XSA-140 version 3 QEMU leak of uninitialized heap memory in rtl8139 device model UPDATES IN VERSION 3 ==================== Normalize version tags. 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. CREDITS ======= This issue was discovered by Donghai Zhu of Alibaba. RESOLUTION ========== Applying the appropriate attached patches resolves this issue. xsa140-qemuu-unstable-?.patch qemu-xen master, 4.5.x, 4.4.x xsa140-qemuu-4.3-?.patch qemu-xen 4.3.x, 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 -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmV8b+8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ8fgH/j3phBHA5Pe7ofmtt/ZNvUOlVyLZD59p9GHOn4Hn liscQDPtHT1paJs3cFw+Pyr3G0utSlmPHQtis6Gfi9bs6QWcA3KLG53UjK51DoEa 7hoj2lyipoztxkPam/34JHOK2KB2tFLBjTMVh9Er38caxVAFV6HkD23FIPRWZw+9 vbCkU9R2SWs5YcyR8VOO9q58BvbIE89JkQGZmDTqjMQ5giAiGpIpwif0lfwOqBy5 +BFWDAKu5BG1LmrCU96Tq42HfBWizjN7aCVWPArGlryGCu1A0qSGXauF008cNWc4 bvv+HQmi1L3FHxE5ZPexKv4U4YAKJXMgV5NQemF0eN0ydzo= =7FDP -----END PGP SIGNATURE-----