Date: Wed, 22 Apr 2015 13:21:20 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security@....org> Subject: Xen Security Advisory 132 (CVE-2015-3340) - Information leak through XEN_DOMCTL_gettscinfo -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-3340 / XSA-132 version 2 Information leak through XEN_DOMCTL_gettscinfo UPDATES IN VERSION 2 ==================== CVE assigned. ISSUE DESCRIPTION ================= The handler for XEN_DOMCTL_gettscinfo failed to initialize a padding field subsequently copied to guest memory. A similar leak existed in XEN_SYSCTL_getdomaininfolist, which is being addressed here regardless of that operation being declared unsafe for disaggregation by XSA-77. IMPACT ====== Malicious or buggy stub domain kernels or tool stacks otherwise living outside of Domain0 may be able to read sensitive data relating to the hypervisor or other guests not under the control of that domain. VULNERABLE SYSTEMS ================== Xen 4.0.x and later are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. The vulnerability is only exposed to service domains with privilege over another guest. In a usual configuration that means only device model emulators (qemu-dm) when these are running in a separate domain. In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable. This vulnerability is applicable for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by "device_model_stubdomain_override=1" in the xl domain configuration file). In this case a guest which has already exploited another vulnerability, to gain control of the device model, would be able to exercise the information leak. However, the security of a system with qemu-dm running in a stub domain is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm. Finally, in a radically disaggregated system, where the service domain software (probably, the device model domain image in the HVM case) is not always supplied by the host administrator, a malicious service domain administrator can exercise this vulnerability. MITIGATION ========== There is no mitigation available. In a radically disaggregated system, restricting HVM service domains to software images approved by the host administrator will avoid the vulnerability (so long as there isn't also a vulnerability in the service domain). NOTE REGARDING LACK OF EMBARGO ============================== The fix for this bug was publicly posted on xen-devel, before it was appreciated that there was a security problem. CREDITS ======= This issue was recognized as security issue by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa132-unstable.patch xen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x xsa132-4.2.patch Xen 4.2.x $ sha256sum xsa132*.patch 3a28eb33c02360ec22c51824e469b1cf6be87941256d0b3aa34a5bd1d7735328 xsa132-4.2.patch 329d4edf1e1133795ece41f2fc8887c5f4cc06b42ced63c810c610b17bcee46d xsa132.patch $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVN6AYAAoJEIP+FMlX6CvZ6R8H/Rq4H94uwp/c8mYM/DHFJf1S YXWGD7jtYYAArAKwG+b3mDYQVzaDhsUR76jS6lssoSWQbSHmqzAKWjZ01Rd5EQDW PqLNwtmIkj9hXCxJdpNubxbr12j0TWzIAOpsUj5alDoy7TaNVMNLG7zSj+jOyNzp uCgIo7TGwWu6OS1xBYZay18oTjv8rEifQgJ8CBRUZHG+xezm94Gbz0iJaonm4bY3 Rjl7U3hfk0O74ncthHOJM5bVTXyDefxeZsR1xkRIWk15GSZ9FXguwfny/m0NQC7Y 7OfGyOyOT27AbxYTOnn30XYwmPAzhw1jrEpdbAwSjxvzRe9iKoxwhezrzgXQ+Q0= =1c8S -----END PGP SIGNATURE----- [ CONTENT OF TYPE application/octet-stream SKIPPED ] [ CONTENT OF TYPE application/octet-stream SKIPPED ]
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ