Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1566253 - (CVE-2018-10472) CVE-2018-10472 xsa258 xen: Information leak via crafted user-supplied CDROM
CVE-2018-10472 xsa258 xen: Information leak via crafted user-supplied CDROM
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20180425:1200,...
: Security
Depends On: 1571867
Blocks: 1566254
  Show dependency treegraph
 
Reported: 2018-04-11 17:18 EDT by Laura Pardo
Modified: 2018-04-30 10:21 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-12 08:18:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laura Pardo 2018-04-11 17:18:06 EDT
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.
Comment 1 Adam Mariš 2018-04-25 10:51:28 EDT
Acknowledgments:

Name: the Xen project
Upstream: Anthony Perard (Citrix)
Comment 2 Adam Mariš 2018-04-25 10:51:40 EDT
External References:

https://xenbits.xen.org/xsa/advisory-258.html
Comment 3 Adam Mariš 2018-04-25 10:52:15 EDT
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1571867]

Note You need to log in before you can comment on or make changes to this bug.