[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-users] Xen Security Advisory 215 - possible memory corruption via failsafe callback
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory XSA-215 version 2 possible memory corruption via failsafe callback UPDATES IN VERSION 2 ==================== Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION ================= Under certain special conditions Xen reports an exception resulting from returning to guest mode not via ordinary exception entry points, but via a so call failsafe callback. This callback, unlike exception handlers, takes 4 extra arguments on the stack (the saved data selectors DS, ES, FS, and GS). Prior to placing exception or failsafe callback frames on the guest kernel stack, Xen checks the linear address range to not overlap with hypervisor space. The range spanned by that check was mistakenly not covering these extra 4 slots. IMPACT ====== A malicious or buggy 64-bit PV guest may be able to modify part of a physical memory page not belonging to it, potentially allowing for all of privilege escalation, host or other guest crashes, and information leaks. VULNERABLE SYSTEMS ================== 64-bit Xen versions 4.6 and earlier are vulnerable. Xen versions 4.7 and later are not vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. Only x86 systems with physical memory extending to a configuration dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are actually affected depends on actual physical memory layout. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION ========== Running only HVM or 32-bit PV guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS ======= This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION ========== Applying the attached patch resolves this issue. xsa215.patch Xen 4.6.x, Xen 4.5.x $ sha256sum xsa215* 5be4ff661dd22890b0120f86beee3ec809e2a29f833db8c48bd70ce98e9691ee xsa215.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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJZCGsCAAoJEIP+FMlX6CvZulUH/38S+01LCZXAyAiPQTKGtJ09 QZeqIriU1rFn/jXWvxnlC2eaKmrZvucOtYWK5Uccmj49Y2lgvoxTqSCa0S86POWU xvwBH2nGMsJ0Q4m1qQ4fZQ3lSsRlRoz0FyeTwdjdGlGVqGqPhDqB7Nm68IyOjr5j zhIxl8WCQulaqlWwCIgR+KQEgbyVDdsqmOYq7vIrYvyEEtM98l2sQ4E5kO3QfxUV aRbUBH4XrleGYNXQE3kXCNBJJIxl8LwsIHvk55hWAjEwmdRbu8o4+eBNn+lvDzQb +AEMk1VrDMYCsxB6bUryJm6AzNc69vBNsdgGo4o0UXZtrfhtyBsEXD6daWqu3/c= =zQpX -----END PGP SIGNATURE----- Attachment:
xsa215.patch _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx https://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |