|Public release ||2017-03-14 11:58|
|Updated ||2017-03-14 11:58|
|Title ||Cirrus VGA Heap overflow via display refresh|
Filesadvisory-211.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2016-9603 / XSA-211
Cirrus VGA Heap overflow via display refresh
UPDATES IN VERSION 2
Patches for qemu-xen-traditional.
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.
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.
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
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.
The discoverer of this issue requested to remain anonymous.
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 and later
xsa211-qemut-4.5.patch qemu-xen-traditional 4.4 and 4.5
$ sha256sum xsa211*
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
(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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
Xenproject.org Security Team