[Xen-devel] Xen Security Advisory 258 - Information leak via crafted user-supplied CDROM

[Xen.org security team <security@xxxxxxx>]

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

                    Xen Security Advisory XSA-258
                              version 2

           Information leak via crafted user-supplied CDROM

UPDATES IN VERSION 2
====================

Public release.

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

QEMU handles many different file formats for virtual disks (e.g., raw,
qcow2, vhd, &c).  Some of these formats are "snapshots" that specify
"patches" to an alternate disk image, whose filename is included in
the snapshot file.

When qemu is given a disk but the type is not specified, it attempts
to guess the file format by reading it.  If a disk image is intended
to be 'raw', but the image is entirely controlled by an attacker, the
attacker could write a header to the image, describing one of these
"snapshot" formats, and pointing to an arbitrary file as the "backing"
file.

When attaching disks via command-line parameters at boot time
(including both "normal" disks and CDROMs), libxl specifies the
format; however, when inserting a CDROM live via QMP, the format was
not specified.

IMPACT
======

An attacker supplying a crafted CDROM image can read any file (or
device node) on the dom0 filesystem with the permissions of the qemu
devicemodel process.  (The virtual CDROM device is read-only, so
no data can be written.)

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

Only x86 HVM guests with a virtual CDROM device are affected.  ARM
guests, x86 PV guests, x86 PVH guests, and x86 HVM guests without a
virtual CDROM device are not affected.

Only systems with qemu running in dom0 are affected; systems running
stub domains are not affected.  Only systems using qemu-xen (aka
"qemu-upstream" are affected; systems running qemu-xen-traditional
are not affected.

Only systems in which an attacker can provide a raw CDROM image, and
cause that image to be virtually inserted while the guest is running,
are affected.  Systems which only have host administrator-supplied
CDROM images, or systems which allow images to be added only at boot
time, are not affected.

MITIGATION
==========

One workaround is to "wrap" the guest-supplied image in a specific
format; i.e., accept a raw image from the untrusted user, and convert
it into qcow2 format; for example:

    qemu-img convert -f raw -O qcow2 untrusted.raw wrapped.qcow2

WARNING: Make sure to specify `-f raw` if you do this, or qemu will
"guess" the format of "untrusted.raw" (which the attacker may have
crafted to look like a qcow2 snapshot image with an alternativee base).

Another workaround is to allow guests to only change CDROMs at boot
time, not while the guest is running.

CREDITS
=======

This issue was discovered by Anthony Perard of Citrix.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

xsa258.patch           xen-unstable, Xen 4.10.x, Xen 4.9.x
xsa258-4.8.patch       Xen 4.8.x, Xen 4.7.x
xsa258-4.6.patch       Xen 4.6.x

$ sha256sum xsa258*
2c35a77eeca5579b5c32517c5ba511c836fa70f8b824ca8883fc6e1a7e608405  xsa258.meta
7e8014deae4fa19464fe6570d0719f8f0d7730dd153d58b2fa38b0cd5ed2e459  xsa258.patch
2c58060a42dafbf65563941dd8c737732124b49eb47007cc60f647553227f557  
xsa258-4.6.patch
ebba2f1f084249cd1e1c2f59e338412161884c31c83dbba03fc1e10bf4ba57a1  
xsa258-4.8.patch
$

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

Deployment of the patches and/or the "wrap" mitigation 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, deploying the "only allow guests to change CDROMs at boot
time" 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
it may give attackers a hint of where to look for the vulnerability.
Deployment of this mitigation is permitted only AFTER the embargo
ends.

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-----
Version: GnuPG v1

iQEcBAEBCAAGBQJa4G55AAoJEIP+FMlX6CvZHjYIAJEtdHT5yPyQuSjh8ATOYN/s
DrpUSw65EvvgbuGJTcmWZMc335AvyoMDtYVtk+Ouy5dMlfuUXcwjimoLWC6FfEDg
aJ19puvjVaA8JcRzimlWQjru8Eqyso1+uNjuvsv1RCSkhN6qGBGCx6xlyWJL0tGk
H/C9HPT7EAKw0bfyFJLOkl7PEohMxXSvGa9oiOZfEJnyr91AuvehTrQWM2Dwf2sz
sXp2drOlWQphwE3o/D+qDv5LOkyJY1NaKvGtTem3TmNT/YImMCWLZ3bS76GDE0io
qsMPHwndwMKDM7ST9bYcKy1Oq2f7DXHBcLVUtn1Q3DhPeSqBmxAfBuESveUIOl4=
=nyQb
-----END PGP SIGNATURE-----

Attachment: xsa258.meta
Description: Binary data

Attachment: xsa258.patch
Description: Binary data

Attachment: xsa258-4.6.patch
Description: Binary data

Attachment: xsa258-4.8.patch
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel