Information

AdvisoryXSA-209
Public release 2017-02-21 10:42
Updated 2023-12-15 15:35
Version 5
CVE(s) CVE-2017-2620
Title cirrus_bitblt_cputovideo does not check if memory region is safe

Files

advisory-209.txt (signed advisory file)
xsa209-qemut.patch
xsa209-qemuu/0001-display-cirrus-ignore-source-pitch-value-as-needed-i.patch
xsa209-qemuu/0002-cirrus-add-blit_is_unsafe-call-to-cirrus_bitblt_cput.patch

Advisory


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2017-2620 / XSA-209
                              version 5

   cirrus_bitblt_cputovideo does not check if memory region is safe

UPDATES IN VERSION 5
====================

Normalize version tags.

ISSUE DESCRIPTION
=================

In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine
cirrus_bitblt_cputovideo fails to check wethehr the specified memory
region is safe.

IMPACT
======

A malicious guest administrator can cause an out of bounds memory
write, very likely exploitable as a privilege escalation.

VULNERABLE SYSTEMS
==================

Versions of qemu shipped with all Xen versions are vulnerable.

Xen systems running on x86 with HVM guests, with the qemu process
running in dom0 are vulnerable.

Only guests provided with the "cirrus" emulated video card can exploit
the vulnerability.  The non-default "stdvga" emulated video card is
not vulnerable.  (With xl the emulated video card is controlled by the
"stdvga=" and "vga=" domain configuration options.)

ARM systems are not vulnerable.  Systems using only PV guests are not
vulnerable.

For VMs whose qemu process is running in a stub domain, a successful
attacker will only gain the privileges of that stubdom, which should
be only over the guest itself.

Both upstream-based versions of qemu (device_model_version="qemu-xen")
and `traditional' qemu (device_model_version="qemu-xen-traditional")
are vulnerable.

MITIGATION
==========

Running only PV guests will avoid the issue.

Running HVM guests with the device model in a stubdomain will mitigate
the issue.

Changing the video card emulation to stdvga (stdvga=1, vga="stdvga",
in the xl domain configuration) will avoid the vulnerability.

CREDITS
=======

This issue was discovered by Gerd Hoffmann of Red Hat.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa209-qemuu/*.patch     qemu-xen, qemu-upstream
xsa209-qemut.patch       qemu-xen-traditional

$ sha256sum xsa209* xsa209*/*
167af9ed7163fa7cf4abb52f865290ced3163c7684151bdc1324eb5e534faf13  xsa209-qemut.patch
e698b73d8de24af0fe33968a43561e5e1d094f4caf2443caa447b552677d2683  xsa209-qemuu/0001-display-cirrus-ignore-source-pitch-value-as-needed-i.patch
50c60e45151ef2265cce4f92b204e9fd75f8bc8952f097e77ab4fe1c1446bc98  xsa209-qemuu/0002-cirrus-add-blit_is_unsafe-call-to-cirrus_bitblt_cput.patch

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

However, deployment of the "stdvga" mitigation (changing the video
card emulation to stdvga) is NOT permitted (except where all the
affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List).  Specifically, deployment on public cloud systems
is NOT permitted.  This is because this produces a guest-visible
change which will indicate which component contains the vulnerability.

Additionally, 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+FMlX6CvZ3jUH/R8iwcZZhvL/kcoL0BNeYrZwJRBD9KLyySLqGYM9
opwimkIGJKOFyxm2MVUMOJj8/7PIqXggoJfCF+87D1F0RhcKcGB9hEKXzxTEpGfy
Vx4I+piOVTKXd2NZctw91UJf4xs7WK9xfIv1NwqtNbCy2ccOtPjrY5AVP/SU2Ev/
7ncPZBJ/gJPjw/p8kdZiHgY7svdyIgoQLb4sh21py/wKZWRrqGTpol4PBC3iwkfZ
ZP5uJ5gMczpd+Mw2/Mi7m5fXOg1xA1lHUEq3NzVEMdpOoeg960Woiz1GQry1TRRN
TTA+GCy0x3L6fTr2fkXnwwy7tbneDDBEzZ68+aa1UhLddTs=
=fbzX
-----END PGP SIGNATURE-----


Xenproject.org Security Team