-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2016-9603 / XSA-211 version 3 Cirrus VGA Heap overflow via display refresh UPDATES IN VERSION 3 ==================== Normalize version tags by ensuring at least two spaces between glob and tag. ISSUE DESCRIPTION ================= When a graphics update command gets passed to the VGA emulator, there are 3 possible modes that can be used to update the display: * blank - Clears the display * text - Treats the display as showing text * graph - Treats the display as showing graphics After the display geometry gets changed (i.e., after the CIRRUS VGA emulation has resized the display), the VGA emulator will resize the console during the next update command. However, when a blank mode is also selected during an update, this resize doesn't happen. The resize will be properly handled during the next time a non-blank mode is selected during an update. However, other console components - such as the VNC emulation - will operate as though this resize had happened. When the display is resized to be larger than before, this can result in a heap overflow as console components will expect the display buffer to be larger than it is currently allocated. IMPACT ====== A privileged user within the guest VM can cause a heap overflow in the device model process, potentially escalating their privileges to that of the device model process. VULNERABLE SYSTEMS ================== All versions of Xen are vulnerable. Only HVM guests with the Cirrus video card are vulnerable. (The Cirrus video card is the default.) Both qemu-upstream and qemu-traditional are vulnerable. For HVM guests with the device model running in a stub domain, "the privileges of the device model process" are identical to those of the guest kernel. But the ability of a userspace process to trigger this vulnerability via legitimate commands to the kernel driver (thus elevating its privileges to that of the guest kernel) cannot be ruled out. MITIGATION ========== Running only PV guests, or running HVM guests with the stgvga driver, will avoid this vulnerability. Running HVM guests with stub domains will mitigate the vulnerability to at most a guest kernel privilege escalation. CREDITS ======= The discoverer of this issue requested to remain anonymous. RESOLUTION ========== Applying the appropriate attached patch resolves this issue (and any further bitblit vulnerabilities) by disabling the bitblit functionality from the Cirrus VGA device entirely. xsa211-qemuu.patch qemu-upstream master xsa211-qemuu-4.8.patch qemu-upstream 4.8 xsa211-qemuu-4.7.patch qemu-upstream 4.7 xsa211-qemuu-4.6.patch qemu-upstream 4.6 and 4.5 xsa211-qemuu-4.4.patch qemu-upstream 4.4 xsa211-qemut.patch qemu-xen-traditional 4.6 - master xsa211-qemut-4.5.patch qemu-xen-traditional 4.4 and 4.5 $ sha256sum xsa211* 9d0cf413dcc9654ee95f6b04fa9c5714f36775cbc9ab0390a3041ec4a68845ab xsa211-qemut.patch d307d67fbf3707a324da537e593702eaff3df2068b559ef19e857b493881155e xsa211-qemut-4.5.patch 0fe17378cf2bc2742f068adf31331f36e01b0f4ffa9c596160fdba2bed3e870a xsa211-qemuu.patch 1808aa443123d8713241a60021507a4d9c142c3cd07233e2f38e9b9b28025ae2 xsa211-qemuu-4.4.patch 5053c7cb392f34a234287092293bb91f261ed68f4b58fe856fe353b647ed5beb xsa211-qemuu-4.6.patch c5884bd441ae8cecce84385c99bcb72ba0eae480a013846fa59c1255aef4808f xsa211-qemuu-4.7.patch bea7cf4065bd9d0085f4dfc3395e59c3ca9d4de9d786a3018c8dc7fd9f3d8b6e xsa211-qemuu-4.8.patch $ NOTE REGARDING EMBARGO ====================== The embargo period is much shorter than our standard two-week period. This is at the request of the discoverer. DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or the mitigation of running with an HVM stub domain (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. It is NOT permitted during the embargo to switch from Cirrus VGA to Stdvga on public-facing systems with untrusted guest users or administrators. This is because it may give a clue where the issue lies. This mitigation is only permitted AFTER the embargo ends. As always, 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/YMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZFuUH/Apms6qkJRrdWtmlYEr2XmjM43vjkyrFDhdM1o7g ynPtaCu5clhDAHLDDxm/kARY8uUWc2YU32ho5zAsQZDaDjeLm3lJspTf09rQlvFk 238pD2qD4pTa4IJJOEVH8GSkbkWF69NXIw/Ih3w0G0h0wsyUV0QQOPIkYJJshfSt SIWOPweLlm2qK50Pf63ERIk4Z1bnPennPN9wuGwQl+rgyPaK8HydVwUixFeDBhSm x2UiSuKaw2md2XHIJSfNM+tQRDAVdjC1zqPNaEd3EdmJjcLlfswSJBEPY0Tm9Hhe MTbOxX0qBl6wPzd6kblUjIVod8dXuNyVYE3kIvx3NO1/m8c= =c+sN -----END PGP SIGNATURE-----