Bug 642934

+++ This bug was initially created as a clone of Bug #641008 +++

Description of problem:
There is a well-known problem with automatic volume format detection in qemu: if a disk was originally raw and qemu is configured to auto-detect disk formats, a malicious guest administrator can add a qcow2 header to the beginning of the raw disk which specifies an alternate backing store, for example a file or block device on the virtualisation host. After reboot, qemu will incorrectly detect the block device as qcow2, and deliver the backing store data to the guest. In this way, a guest administrator can compromise the host. The solution is to specify the disk format to qemu explicitly when launching the host, which disables automatic format detection.

libguestfs doesn't currently allow the format of a disk to be specified explicitly, and therefore always uses automatic format detection. It takes disk images as arguments, and can therefore only be run by the virtualisation administrator. However, if a malicious guest administrator knows that libguestfs will run against their image, they could still use this technique to corrupt the host.

An up-coming feature of virt-v2v (which uses libguestfs) will support format conversion during virt-v2v. Without a way to specify the expected disk format, a malicious guest administrator could use this as an opportunity to copy any file or block device from the host to their guest after conversion.

--- Additional comment from rjones on 2010-10-07 17:13:27 EDT ---

The risk seems to be as follows:

(1) Malicious guest is using a raw-format disk image.

(2) Guest writes a carefully crafted qcow2, VMDK or VDI header
into their own raw disk, and also replaces some binary that one
of our tools might run (/usr/bin/rpm would be a good candidate).
The header says that this (fake) qcow2 image is backed by some
other host file that the guest is interested in reading, eg.
/etc/passwd.  The binary is changed so it reads the backing file
and squirrels the information away somewhere for later use.

(3) Some libguestfs tool runs against the guest.  This tool must
combine the qualities (a || b) && c:
  (a) It opens the guest read-write using guestfs_add_drive _or_
  (b) it enables networking with guestfs_set_network, _and_
  (c) it runs the chosen binary from the guest.

(4) The chosen binary is able to read the backing file (/etc/passwd)
and either store that for later use in the writable disk image or
send it over the network.

I believe that virt-v2v is the only upstream libguestfs-related tool
which is vulnerable, although it's possible boxgrinder is too.

In addition, in RHEL 6.0 networking is always enabled, and that
makes virt-inspector vulnerable as well.

--- Additional comment from pmatouse on 2010-10-08 13:33:31 EDT ---

(In reply to comment #0)
> However, if a malicious guest administrator knows that
> libguestfs will run against their image, they could still use this technique to
> corrupt the host.

My understanding is that there can't be any corruption of host files because of the COW nature of the backing store. So only host files content leakage is possible. Can you please confirm this?

--- Additional comment from pmatouse on 2010-10-08 13:36:30 EDT ---

Maybe libguestfs could (apart from explicitly setting the format on command line) parse libvirt VM configuration files and take the image format from there? I guess libvirt and libguestfs are often used in conjuction (well, at least I do that) for VMs administering tasks.

--- Additional comment from rjones on 2010-10-08 13:59:44 EDT ---

(In reply to comment #2)
> My understanding is that there can't be any corruption of host files because of
> the COW nature of the backing store. So only host files content leakage is
> possible. Can you please confirm this?

It is true that the backing file will not be written to under
any circumstances. This is because libguestfs does not use or
expose the 'commit' functionality of qemu.

I think Matt was mistaken when he said that a malicious guest
could "corrupt the host".  The worst that can happen is that
virt-v2v exits with an error, and this could happen anyway
even without backing files.

The concern in this BZ is that the guest could _read_ a host file,
squirrel that information away somewhere, and next time it
boots use that information for nefarious purposes.  eg. Reading
a password file and trying to crack the passwords at next boot,
or reading a database file and sending that over the network.

(In reply to comment #3)
> Maybe libguestfs could (apart from explicitly setting the format on command
> line) parse libvirt VM configuration files and take the image format from
> there? I guess libvirt and libguestfs are often used in conjuction (well, at
> least I do that) for VMs administering tasks.

Yes, we intend to make this change.  Where libvirt knows the intended
guest format, we will pass that along to qemu (which we are not
doing now).

The open issue is what to do about disk images where we don't
have this information, for example disk images that just exist
on disk and are not associated with a libvirt domain.