Libguestfs doesn't currently allow the format of a disk to be specified explicitly. Because of that malicious guest admin can exploit automatic image format detection in qemu, when the libguestfs is used to administer the image, to read arbitrary file on host via forging a image header with backing store.
--- Additional comment from email@example.com 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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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
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.
Created libguestfs tracking bugs for this issue
Affects: fedora-all [bug 643991]
First part of the fix posted:
Complete upstream fix posted:
This issue has been addressed in following products:
Red Hat Enterprise Linux 6
Via RHSA-2011:0586 https://rhn.redhat.com/errata/RHSA-2011-0586.html