Date: Mon, 19 Dec 2016 15:37:51 +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 204 - x86: Mishandling of SYSCALL singlestep during emulation -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory XSA-204 x86: Mishandling of SYSCALL singlestep during emulation ISSUE DESCRIPTION ================= The typical behaviour of singlestepping exceptions is determined at the start of the instruction, with a #DB trap being raised at the end of the instruction. SYSCALL (and SYSRET, although we don't implement it) behave differently because the typical behaviour allows userspace to escalate its privilege. (This difference in behaviour seems to be undocumented.) Xen wrongly raised the exception based on the flags at the start of the instruction. IMPACT ====== Guest userspace which can invoke the instruction emulator can use this flaw to escalate its privilege to that of the guest kernel. VULNERABLE SYSTEMS ================== All Xen versions are affected. The vulnerability is only exposed to 64-bit x86 HVM guests. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7 and later, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). A 64-bit guest kernel which uses an IST for #DB handling will most likely mitigate the issue, but will have a single unexpected #DB exception frame to deal with. This in practice means that Linux is not vulnerable. The vulnerability is not exposed to 32-bit HVM guests. This is because the emulation bug also matches real hardware behaviour, and a 32-bit guest kernel using SYSCALL will already have to be using a Task Gate for handling #DB to avoid being susceptible to an escalation of privilege. The vulnerability is not exposed to PV guests. ARM systems are not vulnerable. MITIGATION ========== There is no known mitigation. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa204.patch xen-unstable xsa204-4.8.patch Xen 4.8.x xsa204-4.7.patch Xen 4.7.x, Xen 4.6.x xsa204-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa204* 251c33905f86d386cc07240041108ec0664e5e9dddb2b88685d9b4b8ca7fdc24 xsa204.patch e523b65ba122c8e22d32004d2035facaf06295094fdc8b67c151b6f44799ef0b xsa204-4.5.patch d0359f26e9be783672896200e14d85a3111c29d7da580313b593fca04688fef2 xsa204-4.7.patch fa2a69682868104b6263655abbfc6b326f76deebdac3273b4b65da6673f5d977 xsa204-4.8.patch $ NOTE REGARDING EMBARGO ====================== This issue was discussed publicly on qemu-devel before its impact was realised. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYV/5uAAoJEIP+FMlX6CvZnxgIAMXcpEN0qejTe50dAP/gSzzP edi76o/LNGaQBdFRVLvIasRna2TZSXhBNbHPEcAQLPq6pTfQG/HiqdVtftaaaoaG dvNhuDBdZaa1/fmhCV1P+t9vaipp3U3yK2s0eiSJLXp3nGqkgjSSmZloYY0bevDN DJ0uZ7uWkvyN6Tkl6R/h3h9PsgIKPIQBIyBuT2zYPf/JAjBD27ZYX11F9JvVMmt3 JH/AbvJwUsaqNG3teLg+tioQPwHwkZCdxOhG+v2Y3CeqQ1bvNCb5emLtpXFO9h0w kZNh88gT1mwbxDWbF3Ek/OhHbOHosfxi9kn8ib5Yu0P8xRmvYhQHMeQDa/rt9Y0= =OVcU -----END PGP SIGNATURE----- Download attachment "xsa204.patch" of type "application/octet-stream" (2719 bytes) Download attachment "xsa204-4.5.patch" of type "application/octet-stream" (2754 bytes) Download attachment "xsa204-4.7.patch" of type "application/octet-stream" (2754 bytes) Download attachment "xsa204-4.8.patch" of type "application/octet-stream" (2208 bytes)
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